From frode@dxcern.cern.ch Wed Mar 01 04:07:18 1995
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id EAA16148 for <hfsig@tapr.org>; Wed, 1 Mar 1995 04:07:13 -0600
Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14971; Wed, 1 Mar 1995 11:05:33 +0100
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16487; Wed, 1 Mar 1995 11:05:31 +0100
Date: Wed, 1 Mar 1995 11:05:29 +0100 (MET)
From: Frode Weierud <frode@dxcern.cern.ch>
To: HFSIG TAPR <hfsig@tapr.org>
Subject: Reed-Solomon Package
Message-Id: <Pine.ULT.3.91.950301110059.3464A-100000@dxcern.cern.ch>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi all,

I have just uploaded a package of routines for experimenting with 
Reed-Solomon error correcting codes on ftp.tapr.org, in the
tapr/SIG/hfsig/upload directory. The archive is called RSpack.zip.

Here is the content of the RSpack.txt file:

RSpack is a complete package for experimenting with Reed-Solomon
error correcting codes. The author of RSpack is:

		Jan-Mark Wams.
      		email: jms@cs.vu.nl 
 		smail: Jan-Mark Wams
          	Jephtastraat 67-5
          	1055 JS  Amsterdam
          	voice: .. (31-20 / 020) 6 81 43 84
      
Here is a short extract from the readme file:

T H E   R S - P A C K A G E 
---------------------------

Below is my RS-package. It should run on MS-DOS and UNIX provided 
a ANSI-C compiler is used (like gcc or turbo C).

It has two main parts:

	 i) A generator program.
	ii) A (en/de)-code program.

The first program (``rsgen.c'') is a C program that generates a
include file for the second program (``rsbody.c''). The 
(en/de)-coding is an example of how the generated file of the
generator program could be used. The net effect of a version 
of the (en/de)-code-program is a filter, that allows one to
protect data. For testing purposes, there is a program for
altering files, and a program for deleting bytes from a file.
These can be used to simulate a bad network.

-------------

I have made some small changes to the original Makefile and a few of
the source files as describes in the readme.1st file. I have also
included a small tutorial on Reed-Solomon codes written by Colin Plumb.

Contributed by Frode Weierud, F/LA2RL
1 March 1995

73 Frode

**************************************************************************
*	Frode Weierud		Phone	:	41 22 7674794		 *
*	CERN, SL		Fax	:	41 22 7679185		 *
*	CH-1211 Geneva 	23	E-mail	:	frode@dxcern.cern.ch	 *
*	Switzerland							 *
**************************************************************************

From SJF@rpsl.co.uk Wed Mar 01 04:22:36 1995
Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id EAA16348 for <hfsig@tapr.org>; Wed, 1 Mar 1995 04:22:31 -0600
Received: from rpsl.demon.co.uk by post.demon.co.uk id aa08402;
          1 Mar 95 10:19 GMT
Received: from mail.rpsl.co.uk by rpsl.demon.co.uk with SMTP
	id AA3523 ; Wed, 01 Mar 95 10:25:03 GMT
Received: from RPSL/SpoolDir by mail.rpsl.co.uk (Mercury 1.13);
    Wed, 1 Mar 95 10:19:43 GMT
Received: from SpoolDir by RPSL (Mercury 1.13); Wed, 1 Mar 95 10:18:34 GMT
From: STUART FAWCETT <SJF@rpsl.co.uk>
Organization:  Racal Positioning Systems Limited
To: hfsig@tapr.org
Date:          Wed, 1 Mar 1995 10:18:34 GMT
Subject:       
Priority: normal
X-mailer:     Pegasus Mail/Windows (v1.11a)
Message-ID: <300F4F20E36@mail.rpsl.co.uk>

Subscribe
From kurpiers@zeus.uet.e-technik.th-darmstadt.de Wed Mar 01 12:03:36 1995
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id MAA18979 for <hfsig@tapr.org>; Wed, 1 Mar 1995 12:03:04 -0600
Received: from zeus.uet.e-technik.th-darmstad (zeus.uet.e-technik.th-darmstadt.de) by rs2.hrz.th-darmstadt.de with SMTP id AA16952
  (5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Wed, 1 Mar 1995 19:00:47 +0100
Received: from hades.uet.e-technik.th-darmsta (hades.uet.e-technik.th-darmstadt.de [130.83.18.78]) by zeus.uet.e-technik.th-darmstadt (8.6.4/8.6.4) with ESMTP id TAA19385 for <hfsig@tapr.org>; Wed, 1 Mar 1995 19:00:43 +0100
From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de>
Received: from localhost (kurpiers@localhost) by hades.uet.e-technik.th-darmstad (8.6.4/8.6.4) id SAA17859 for hfsig@tapr.org; Wed, 1 Mar 1995 18:58:38 +0100
Message-Id: <199503011758.SAA17859@hades.uet.e-technik.th-darmstad>
Subject: Re: HF Channel Simulator
To: hfsig@tapr.org
Date: Wed, 1 Mar 1995 18:58:37 +0100 (MEZ)
In-Reply-To: <34280A72BE9@frl.orst.edu> from "Johan Forrer" at Feb 28, 95 11:31:40 am
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2038      

> The procedure is as follows (this is performed in triplicate):
> 
> 1). Create White Gaussian noise with a given standard deviation as
>     determined by the CCIR conditions that you are simulating.
> 
> 2). Apply a complex low-pass filter to the points (complex) created
>     in (1). A Butterworth response is probably a good choice for 
>     having low ripple in the pass band. A two-pole filter is quite    
>     adequate.
> 
>  ...
> 
> Johan, KC7WW

The generated Gaussian noise is white in the frequency domain. From the CCIR
report and from the Watterson paper it is clear, that the tap-gain function
spectrum is the sum of two Gaussian functions of frequency. So I still
think you have to use filters with Gaussian frequency response to convert
the white noise to the spectrum we need. Furthermore, the CCIR report
states that not only the tap-gain function has a Gaussian frequency
spectrum with high probability but that a single-pole spectrum is not
valid. So a two-pole filter can't be anything more but an approximation.

The filters with Gaussian frequency response can easily be implemented as
FIR filters (ok, Butterworth IIR filters would be easier... :-) ).
 
As this is a rather important part of the simulator I think it is still
important to talk about this filter...

73' Alexander DL8AAU


*--------------------------------------------------------------*
|        Alexander F. Kurpiers                                 |
|        Technische Hochschule Darmstadt                       |
|        Institut fuer Uebertragungstechnik                    |
|        Merckstrasse 25                                       |
|        D-64283 Darmstadt (Germany)                           |
|        Voice: +49-6151-162369                                |
|        Fax  : +49-6151-165545                                |
|        EMail: kurpiers@zeus.uet.e-technik.th-darmstadt.de    |
|        Hamradio: dl8aau@db0kg.#nds.deu.eu                    |
*--------------------------------------------------------------*


 
From mcdermot@aud.alcatel.com Wed Mar 01 14:13:57 1995
Received: from aud.alcatel.com ([198.64.191.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id OAA20280 for <hfsig@tapr.org>; Wed, 1 Mar 1995 14:13:50 -0600
Received: by janus01.aud.alcatel.com id <20629>; Wed, 1 Mar 1995 14:11:22 -0600
Date: Wed, 1 Mar 1995 14:11:49 -0600
From: mcdermot@aud.alcatel.com (Tom Mcdermott)
To: hfsig@tapr.org
Subject: Re: [HFSIG:297] Re: HF Channel Simulator
Message-Id: <95Mar1.141122cst.20629@janus01.aud.alcatel.com>


> > The procedure is as follows (this is performed in triplicate):
> > 
> > 1). Create White Gaussian noise with a given standard deviation as
> >     determined by the CCIR conditions that you are simulating.
> > 
> > 2). Apply a complex low-pass filter to the points (complex) created
> >     in (1). A Butterworth response is probably a good choice for 
> >     having low ripple in the pass band. A two-pole filter is quite    
> >     adequate.
> > 
> >  ...
> > 
> > Johan, KC7WW
> 
> The generated Gaussian noise is white in the frequency domain. From the CCIR
> report and from the Watterson paper it is clear, that the tap-gain function
> spectrum is the sum of two Gaussian functions of frequency. So I still
> think you have to use filters with Gaussian frequency response to convert
> the white noise to the spectrum we need. Furthermore, the CCIR report
> states that not only the tap-gain function has a Gaussian frequency
> spectrum with high probability but that a single-pole spectrum is not
> valid. So a two-pole filter can't be anything more but an approximation.
> 
> The filters with Gaussian frequency response can easily be implemented as
> FIR filters (ok, Butterworth IIR filters would be easier... :-) ).
>  
> As this is a rather important part of the simulator I think it is still
> important to talk about this filter...
> 
> 73' Alexander DL8AAU
> 


	Alexander:  I believe what the CCIR report requires is that the doppler
frequency have a gaussian-distributed probability density function (PDF).
This is not the same as the amplitude response of the filter.  The gaussian
PDF is generated by a gaussian random number generator.   Since gaussian
noise has a flat frequency response, a low pass filter obviously distorts
the PDF.  But a gaussian-amplitude LPF does not mean the the PDF of the
output of the LPF is gaussian, because the LPF would have to be flat
(ie no filter) to have gaussian PDF.  Remember, gaussian PDF -> white noise
(spectally flat, not shaped), and not-flat spectrum -> non-gaussian.

So, the filter function does not alter the statistics of the distribution in
a readily recognizable way.  As the filter bandwidth changes, the
standard-deviation of the distribution changes, since we are changing how
the random numbers are being averaged -- this is equivalent to saying that the
energy in the signal is changed, since RMS = Std. Dev.

The math behind linear amplitude transformation of PDF's, and the resulting
PDF is not readily available in the EE literature (well, I haven't
seen it anyway).  However, the math behind the summation of 
gaussian-distributed random numbers is well documented.  In amplitude,
the sum of multiple gaussian numbers with non-zero mean leads to a Rayleigh
distribution (PDF) of the resultant amplitude.  So this corresponds to the 
requirement that the path component have Rayleigh fading.

How often the fade occurs is related to the doppler frequency.  So a
wider low pass filter yields faster fading, equivalent to a larger
std deviation of the doppler frequency.  The sum of gaussian-distributed
complex random numbers generates a random phase with a uniform distribution,
and this matches the requirement that the phase of the path component be 
uniformly distributed.

So, even without filtering, the doppler is gaussian-distributed.  The purpose
of the filter then is just to set the doppler rate, so we can control it
for simulating different band conditions.

							- Tom, N5EG


ps: I have no training in the area of stochastic processes, someone who
has been there before can give us a discourse on what spectral filtering
does to PDF's!  It is a difficult job to mentally keep separate amplitude
spectrum and PDF.

From rick@itron-ca.com Wed Mar 01 16:58:53 1995
Received: from itron-ca.com (gate.itron-ca.com [204.30.20.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id QAA21383 for <hfsig@tapr.org>; Wed, 1 Mar 1995 16:58:43 -0600
Received: (from audit@localhost) by itron-ca.com (8.6.9/8.6.9) id OAA16431; Wed, 1 Mar 1995 14:56:52 -0800
Received: from unknown(204.30.20.118) by gate.itron-ca.com via smap (V1.3mjr)
	id sma016429; Wed Mar  1 14:56:11 1995
Date: Wed,  1 Mar 95 14:53:22 PST
From: "Richard W. D. Booth" <rick@itron-ca.com>
Subject: RE: [HFSIG:298] Re: HF Channel Simulator 
To: hfsig@tapr.org
X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc.
Message-ID: <Chameleon.4.01.950301145609.rick@rick.itron-ca.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Tom,
The output of a linear filter driven by a gaussian random process is still a gaussian 
random process...the spectrum (or autocorrelation function, if you will) is modified by the 
properties of the filter so the correlation between samples is modified.
Rick
w6nzk
>
>> > The procedure is as follows (this is performed in triplicate):
>> > 
>> > 1). Create White Gaussian noise with a given standard deviation as
>> >     determined by the CCIR conditions that you are simulating.
>> > 
>> > 2). Apply a complex low-pass filter to the points (complex) created
>> >     in (1). A Butterworth response is probably a good choice for 
>> >     having low ripple in the pass band. A two-pole filter is quite    
>> >     adequate.
>> > 
>> >  ...
>> > 
>> > Johan, KC7WW
>> 
>> The generated Gaussian noise is white in the frequency domain. From the CCIR
>> report and from the Watterson paper it is clear, that the tap-gain function
>> spectrum is the sum of two Gaussian functions of frequency. So I still
>> think you have to use filters with Gaussian frequency response to convert
>> the white noise to the spectrum we need. Furthermore, the CCIR report
>> states that not only the tap-gain function has a Gaussian frequency
>> spectrum with high probability but that a single-pole spectrum is not
>> valid. So a two-pole filter can't be anything more but an approximation.
>> 
>> The filters with Gaussian frequency response can easily be implemented as
>> FIR filters (ok, Butterworth IIR filters would be easier... :-) ).
>>  
>> As this is a rather important part of the simulator I think it is still
>> important to talk about this filter...
>> 
>> 73' Alexander DL8AAU
>> 
>
>
>	Alexander:  I believe what the CCIR report requires is that the doppler
>frequency have a gaussian-distributed probability density function (PDF).
>This is not the same as the amplitude response of the filter.  The gaussian
>PDF is generated by a gaussian random number generator.   Since gaussian
>noise has a flat frequency response, a low pass filter obviously distorts
>the PDF.  But a gaussian-amplitude LPF does not mean the the PDF of the
>output of the LPF is gaussian, because the LPF would have to be flat
>(ie no filter) to have gaussian PDF.  Remember, gaussian PDF -> white noise
>(spectally flat, not shaped), and not-flat spectrum -> non-gaussian.
>
>So, the filter function does not alter the statistics of the distribution in
>a readily recognizable way.  As the filter bandwidth changes, the
>standard-deviation of the distribution changes, since we are changing how
>the random numbers are being averaged -- this is equivalent to saying that the
>energy in the signal is changed, since RMS = Std. Dev.
>
>The math behind linear amplitude transformation of PDF's, and the resulting
>PDF is not readily available in the EE literature (well, I haven't
>seen it anyway).  However, the math behind the summation of 
>gaussian-distributed random numbers is well documented.  In amplitude,
>the sum of multiple gaussian numbers with non-zero mean leads to a Rayleigh
>distribution (PDF) of the resultant amplitude.  So this corresponds to the 
>requirement that the path component have Rayleigh fading.
>
>How often the fade occurs is related to the doppler frequency.  So a
>wider low pass filter yields faster fading, equivalent to a larger
>std deviation of the doppler frequency.  The sum of gaussian-distributed
>complex random numbers generates a random phase with a uniform distribution,
>and this matches the requirement that the phase of the path component be 
>uniformly distributed.
>
>So, even without filtering, the doppler is gaussian-distributed.  The purpose
>of the filter then is just to set the doppler rate, so we can control it
>for simulating different band conditions.
>
>							- Tom, N5EG
>
>
>ps: I have no training in the area of stochastic processes, someone who
>has been there before can give us a discourse on what spectral filtering
>does to PDF's!  It is a difficult job to mentally keep separate amplitude
>spectrum and PDF.
>
>


From kurpiers@zeus.uet.e-technik.th-darmstadt.de Thu Mar 02 02:28:09 1995
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id CAA24942 for <hfsig@tapr.org>; Thu, 2 Mar 1995 02:27:44 -0600
Received: from zeus.uet.e-technik.th-darmstad (zeus.uet.e-technik.th-darmstadt.de) by rs2.hrz.th-darmstadt.de with SMTP id AA40088
  (5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Thu, 2 Mar 1995 09:25:47 +0100
Received: from hades.uet.e-technik.th-darmsta (hades.uet.e-technik.th-darmstadt.de [130.83.18.78]) by zeus.uet.e-technik.th-darmstadt (8.6.4/8.6.4) with ESMTP id JAA11794 for <hfsig@tapr.org>; Thu, 2 Mar 1995 09:25:40 +0100
From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de>
Received: from localhost (kurpiers@localhost) by hades.uet.e-technik.th-darmstad (8.6.4/8.6.4) id JAA09206 for hfsig@tapr.org; Thu, 2 Mar 1995 09:23:34 +0100
Message-Id: <199503020823.JAA09206@hades.uet.e-technik.th-darmstad>
Subject: Re: HF Channel Simulator
To: hfsig@tapr.org
Date: Thu, 2 Mar 1995 09:23:34 +0100 (MEZ)
In-Reply-To: <Chameleon.4.01.950301145609.rick@rick.itron-ca.com> from "Richard W. D. Booth" at Mar 1, 95 05:08:15 pm
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 4956      

> 
> Tom,
> The output of a linear filter driven by a gaussian random process is still a gaussian 
> random process...the spectrum (or autocorrelation function, if you will) is modified by the 
> properties of the filter so the correlation between samples is modified.
> Rick
> w6nzk
> >
Thank you, that's what I wanted to reply when your mail arrived here...

> >
> >	Alexander:  I believe what the CCIR report requires is that the doppler
> >frequency have a gaussian-distributed probability density function (PDF).
> >This is not the same as the amplitude response of the filter.  The gaussian
> >PDF is generated by a gaussian random number generator.   Since gaussian
> >noise has a flat frequency response, a low pass filter obviously distorts
> >the PDF.  But a gaussian-amplitude LPF does not mean the the PDF of the
> >output of the LPF is gaussian, because the LPF would have to be flat
> >(ie no filter) to have gaussian PDF.  Remember, gaussian PDF -> white noise
> >(spectally flat, not shaped), and not-flat spectrum -> non-gaussian.

I know that a Gaussian distributed random variable (so the PDF is
gaussian-distributed) has nothing to do with the power spectral densitiy.
In our case it seems to be clear:
(Watterson, Experimental Confirmation of an HF Channel Model):

Statistical specifications for the tap-gain function involved
three hypotheses: 1.) that each tap-gain function is a complex-Gaussian
                      process that produces Rayleigh fading
                  2.) that the tap-gain functions are independent
                  3.) that each tap-gain function has a spectrum that
                      in general is a sum of two Gaussian functions of
                      FREQENCY, one for each magnetoionic component.

1. is related to the pdf and without 2. we would have trouble implementing
the model. But 3. says clearly, what the psd of the tap-gain functions
have to look like.

> >So, the filter function does not alter the statistics of the distribution in
> >a readily recognizable way.  As the filter bandwidth changes, the
> >standard-deviation of the distribution changes, since we are changing how
> >the random numbers are being averaged -- this is equivalent to saying that the
> >energy in the signal is changed, since RMS = Std. Dev.

I was trying to calculate the RMS and found an equation by numeric
integration. You will have to calculate it, otherwise you have to
estimate the mean signal power at the point, where Gaussian noise is
added to the fading signals (at the output of the HF simulator).

> >The math behind linear amplitude transformation of PDF's, and the resulting
> >PDF is not readily available in the EE literature (well, I haven't
> >seen it anyway).  However, the math behind the summation of 
> >gaussian-distributed random numbers is well documented.  In amplitude,
> >the sum of multiple gaussian numbers with non-zero mean leads to a Rayleigh
> >distribution (PDF) of the resultant amplitude.  So this corresponds to the 
> >requirement that the path component have Rayleigh fading.

As stated above, linear filtered of Gaussian distributed random variables
will still be Gaussian distributed. You can think of the filtering
process as a convolution with the impulse response of the filter. If
you do this convolution with samples of the random variable (discrete time
filtering), it's nothing more than multiplying the samples with constants
and summing the result. As you said, the sum of any number of Gaussian
distributed numbers is Gaussian ... :-)
If you do the filtering continously, the summing will be an integration.

About literature, try Papoulis, "Probability, Random Variables and
Stochastic Processes". The book I'm using here is in German, so it is
probably of no use for you. 

> >How often the fade occurs is related to the doppler frequency.  So a
> >wider low pass filter yields faster fading, equivalent to a larger
> >std deviation of the doppler frequency.  The sum of gaussian-distributed
> >complex random numbers generates a random phase with a uniform distribution,
> >and this matches the requirement that the phase of the path component be 
> >uniformly distributed.

Not only the sum of Gaussian-distributed complex numbers has a random
phase...
The phase of any Gaussian-distributed complex number with zero mean
Gaussian distributed real and imaginary parts is uniform distributed and
the amplitude is Rayleigh distributed.

> >
> >So, even without filtering, the doppler is gaussian-distributed.  The purpose
> >of the filter then is just to set the doppler rate, so we can control it
> >for simulating different band conditions.
> >
> >							- Tom, N5EG
> >
> >
> >ps: I have no training in the area of stochastic processes, someone who
> >has been there before can give us a discourse on what spectral filtering
> >does to PDF's!  It is a difficult job to mentally keep separate amplitude
> >spectrum and PDF.
> >

73' Alexander DL8AAU


From mcdermot@aud.alcatel.com Thu Mar 02 07:50:09 1995
Received: from aud.alcatel.com ([198.64.191.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id HAA25711 for <hfsig@tapr.org>; Thu, 2 Mar 1995 07:50:06 -0600
Received: by janus01.aud.alcatel.com id <20648>; Thu, 2 Mar 1995 07:47:33 -0600
Date: Thu, 2 Mar 1995 07:47:58 -0600
From: mcdermot@aud.alcatel.com (Tom Mcdermott)
To: hfsig@tapr.org
Subject: Re: [HFSIG:299] Re: HF Channel Simulator
Message-Id: <95Mar2.074733cst.20648@janus01.aud.alcatel.com>


> Tom,
> The output of a linear filter driven by a gaussian random process is still a gaussian 
> random process...the spectrum (or autocorrelation function, if you will) is modified by the 
> properties of the filter so the correlation between samples is modified.
> Rick
> w6nzk

	Rick:  I agree.  The power spectral density is, I think, the Fourier
transform of the autocorrelation function, which for zero-mean gaussian
process results in gaussian PSD.  Since the gaussian PSD rolls-off pretty 
fast in amplitude vs. frequency already, the filter shape doesn't mess up
the PSD too much, as long as it is reasonably square-ish (ie several poles).
Sure, the shape is changed, but the error is fairly small, and is ignored
for a multi-pole filter.

	So, filtering the white-noise signal results in another (almost) white
noise signal of lower bandwidth, but is still has pretty much the same PSD
shape except with a lower std. deviation. (PSD is equivalent to a PDF,
I believe).

						- Tom, N5EG
From kurpiers@zeus.uet.e-technik.th-darmstadt.de Thu Mar 02 09:10:59 1995
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id JAA26406 for <hfsig@tapr.org>; Thu, 2 Mar 1995 09:04:52 -0600
Received: from zeus.uet.e-technik.th-darmstad (zeus.uet.e-technik.th-darmstadt.de) by rs2.hrz.th-darmstadt.de with SMTP id AA31934
  (5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Thu, 2 Mar 1995 15:58:52 +0100
Received: from hades.uet.e-technik.th-darmsta (hades.uet.e-technik.th-darmstadt.de [130.83.18.78]) by zeus.uet.e-technik.th-darmstadt (8.6.4/8.6.4) with ESMTP id PAA11903 for <hfsig@tapr.org>; Thu, 2 Mar 1995 15:58:52 +0100
From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de>
Received: from localhost (kurpiers@localhost) by hades.uet.e-technik.th-darmstad (8.6.4/8.6.4) id PAA20626 for hfsig@tapr.org; Thu, 2 Mar 1995 15:56:45 +0100
Message-Id: <199503021456.PAA20626@hades.uet.e-technik.th-darmstad>
Subject: Re: HF Channel Simulator
To: hfsig@tapr.org
Date: Thu, 2 Mar 1995 15:56:44 +0100 (MEZ)
In-Reply-To: <95Mar2.074733cst.20648@janus01.aud.alcatel.com> from "Tom Mcdermott" at Mar 2, 95 07:50:53 am
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1288      

> 
> 	Rick:  I agree.  The power spectral density is, I think, the Fourier
> transform of the autocorrelation function, which for zero-mean gaussian
> process results in gaussian PSD.  Since the gaussian PSD rolls-off pretty 
> fast in amplitude vs. frequency already, the filter shape doesn't mess up
> the PSD too much, as long as it is reasonably square-ish (ie several poles).
> Sure, the shape is changed, but the error is fairly small, and is ignored
> for a multi-pole filter.

You can't tell the psd (power spectral density) from the 
pdf (probability density function), which is a measure for the 
amplitude distribution of a random variable. The psd is related to the
autocorrelation function, it is indeed the Fourier transform of it.

I.e. if the Gaussian distributed random variable is uncorrelated, the
psd is a constant and thus the noise is called white. Filtering this
white noise results in a new more or less correlated random variable
whose pdf is still Gaussian distributed. 

> 
> 	So, filtering the white-noise signal results in another (almost) white
> noise signal of lower bandwidth, but is still has pretty much the same PSD
> shape except with a lower std. deviation. (PSD is equivalent to a PDF,
> I believe).
> 
> 						- Tom, N5EG
> 


73' Alexander DL8AAU
From mcdermot@eagle.aud.alcatel.com Wed Mar 08 09:13:46 1995
Received: from aud.alcatel.com ([198.64.191.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id JAA08003 for <hfsig@tapr.org>; Wed, 8 Mar 1995 09:13:42 -0600
Received: by janus01.aud.alcatel.com id <20587>; Wed, 8 Mar 1995 09:10:39 -0600
Date: Wed, 8 Mar 1995 09:10:30 -0600
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott)
To: hfsig@tapr.org
Subject: Re: HF Channel Simulator
Message-Id: <95Mar8.091039cst.20587@janus01.aud.alcatel.com>



	I have performed some analysis on the question of the shape of
the tap-gain functions.  I now understand Alexander's original question.
My previous statements about the filter shape are not correct.  Here's
what I did, and the results.

1. Generated a real-valued random number stream using gaussian-distributed
random number, and calculated power spectral density (PSD) using two methods,
Fourier transform of autocorrelation integral, and using Welsh's periodogram.
Both give white PSD (ie: flat PSD vs. frequency).

2. Generated a complex-valued random number stream, with I- and Q- components
generated by two independent gaussian-distributed random number sequences.
Using both methods to compute PSD, as above, the PSD was white.  The
amplitude PDF is Rayleigh, the phase PDF is uniform.

3. Designed an IIR LPF filter, 2nd order Butterworth, with corner frequencies
of 0.1, and  0.25.  Then filtered the random sequence generated in step 2 with 
this filter.

4. Calculated the PSD of the filtered signal from step 3 with both methods.
Each gives a lowpass PSD resembling the Butterworth filter response curve.
This corresponds to the tap-gain spectrum, if one looks at the double-sided
spectrum.


Notes from observation of the filter shape of the Butterworth responses:

1st order filter has poor roll-off, the shape does not look like a gaussian
roll-off.  Lot of higher frequency energy.  This results in tap-gain spectrum
that does not look gaussian, ie: too much energy too far away from the 
center frequency -> pessimistic results.

2nd order Butterworth LPF gives very nice roll-off characteristic, closely
matching gaussian response.  It's slightly distorted at low frequency, good
match in transition region and cut-off region.  If one were to generate the
double-sided spectrum, this would give a result matching the gaussian
spectrum roll-off, except that the part in the very center would be squashed
down a little (flat across the top, instead of bullet-nosed).

3rd order Butterworth LPF gives a spectrum with a too-sharp roll-off.  This
would be too rectangular- as compared to the gaussian curve.

So, the conclusion I would reach is that the 2nd order Butterworth is
a pretty good approximation to the gaussian tap-gain spectrum shape.

							- Tom, N5EG


PS:  This discussion over the last week on hfsig has been extremely
educational.  Thanks!

From FORRERJ@frl.orst.edu Thu Mar 09 16:08:19 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id QAA15905 for <HFSIG@tapr.org>; Thu, 9 Mar 1995 16:08:12 -0600
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id GAA18429 for <HFSIG@tapr.org>; Thu, 9 Mar 1995 06:44:48 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Thu, 9 Mar 95 14:04:18 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 9 Mar 95 14:03:53 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Thu, 9 Mar 1995 14:03:44 PST8PDT
Subject:       Annual meeting update
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <41F3CFA3CF9@frl.orst.edu>

Hi All,

Thought that I would welcome all those that joined us after
the TAPR annual meeting.

For those that did not have the opportunity to attend - it was
quite interesting. Was my first time. I was taken with the richness
in diversity of fields of interests and capabilties of participants.

There was a lot of emphasis on DSP. Bob Stricklin made a valiant 
effort to stimulate the discussion in the DSP developer's simposium, 
however, it quickly evolved into a "wishlist for digital radio 
features". In my humble opinion, the opportunity was lost to bring together 
those that are actually developing DSP applications. It was a large 
audience, evidently with lots of different expectations, just my opinion 
that there were too many with other interests that overwhelmed 
the purpose of the meeting.

Tom McDermit, N5EG, made an outstanding presentation on channel
characterization - I certainly enjoyed his approach and 
learned a few things. I am looking forward to Tom's book.

Saturday afternoon, we had an HFSIG meeting that was attended by 
15 - 20 folks. This meeting paralled with another on TCP/IP, so
guess we had the *REAL* HF digital enthusiasts together. I presented
a summary of recent activities that included: the work on the HF channel 
simulator and alternate modulation schemes. I indicated that our efforts 
are focussed on a) methods for high speed communications suitable for
networking applications, and b) low speed, very robust communications to 
operate in adverse conditions. There is a distinction beween these. I 
also discussed some of the results on improving crest factor. It was
evident that the contributions of this SIG was followed by many, and 
with interest. Thanks to all of you for making this possible. 

The dinner presentation was an energetic talk by Paul Schuch on SETI. 

Sunday morning was time for Phil Karn's, KA9Q, exceptionally good 
presentation on error-control coding. It was an ejoyable experience, non-
mathematical, however, with enough depth to get the point across. The 
message was that there is no free lunch - everything is a compromise, the 
main tradeoffs being bandwidth and power. Block codes works better 
when block size is larger. Convolutional codes are more computationally 
expensive, however, yields somewhat better coding gain. Softening up the 
decisions at the descriminator helps a lot. At it simplest, erasure coding 
is a start. However, multiple levels of decision codes does wonders. The 
combination of inner/outer codes was shown to be the ultimate, however, 
probably also the most demanding as far as computations are concerned. 
Phil's talk contained numerous interesting asides of how  professionals 
does it on the deep space projects, i.e., how to get the message across 
when the spacecraft's big antenna is not working as it should. 

Sunday afternoon, Bob Stricklin, and Tom McDermit presented a wealth of
useful information for aspiring DSP-93 programmers. It was a lot of fun 
listening to questions and answers - everyone got their money's worth.

Personally, I thought that it was a worthwhile experience. The board, 
especially Greg Jones, deserves credit for a job well done. The organizers 
also did an outstanding job to make us all feel welcome. It was a wonderful 
auditorium and everything ran like clockwork. 

Thanks all,

73's

Johan, KC7WW

From techman@ace.com Fri Mar 10 02:03:56 1995
Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id CAA18084 for <hfsig@tapr.org>; Fri, 10 Mar 1995 02:03:30 -0600
Received: from uu0924.UUCP by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via UUCP;
        id AA14135 for ; Fri, 10 Mar 95 02:55:40 -0500
Date: Fri, 10 Mar 95 02:33:55 EST
From: techman@ace.com (Techman)
Subject: info
Message-Id: <9503100233.0.UUL1.3#25274@ace.com>
To: hfsig@tapr.org


subscribe
From faunt@netcom.com Fri Mar 10 14:24:01 1995
Received: from netcom2.netcom.com (netcom2.netcom.com [192.100.81.108]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id OAA20491 for <hfsig@tapr.org>; Fri, 10 Mar 1995 14:22:54 -0600
Received: by netcom2.netcom.com (8.6.10/Netcom)
	id JAA20975; Fri, 10 Mar 1995 09:15:42 -0800
Date: Fri, 10 Mar 1995 09:15:42 -0800
From: faunt@netcom.com (Doug Faunt N6TQS 510-655-8604)
Message-Id: <199503101715.JAA20975@netcom2.netcom.com>
To: hfsig@tapr.org
Subject: PacTOR II?

Are there any references available on PacTOR II?
How does it differ from PacTOR?
73, doug
From mcdermot@eagle.aud.alcatel.com Fri Mar 10 15:26:28 1995
Received: from aud.alcatel.com ([198.64.191.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id PAA21304 for <hfsig@tapr.org>; Fri, 10 Mar 1995 15:26:25 -0600
Received: by janus01.aud.alcatel.com id <20555>; Fri, 10 Mar 1995 15:23:07 -0600
Date: Fri, 10 Mar 1995 15:22:50 -0600
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott)
To: hfsig@tapr.org
Subject: Re: [HFSIG:306] PacTOR II?
Message-Id: <95Mar10.152307cst.20555@janus01.aud.alcatel.com>

> Are there any references available on PacTOR II?
> How does it differ from PacTOR?
> 73, doug
> 
	The ADRS Journal for Jan/Feb/Mar has information on Pactor II.
I have Jan and Feb articles - Jan talks about two-tone DPSK and convolutional
coding. Feb issue says little useful.  Mar issue is supposed to say more, 
but am waiting for it.

	So far, it's pretty vague about the exact format.  Requires unit
with a 56000 series DSP and a 68000 series general microprocessor.

	I'm guessing it will say that it is two-tone DBPSK 200-baud per tone,
with rate=1/2 k=9 convolutional coding, and raised-cosine baseband filtering.
But we'll have to wait and see.


							- Tom, N5EG
From karn@qualcomm.com Fri Mar 10 15:41:02 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id PAA21410 for <hfsig@tapr.org>; Fri, 10 Mar 1995 15:40:59 -0600
Received: (karn@localhost) by servo.qualcomm.com (8.6.10/QC-BSD-2.5) id NAA00427; Fri, 10 Mar 1995 13:40:10 -0800
Date: Fri, 10 Mar 1995 13:40:10 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199503102140.NAA00427@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <32B761B3EE3@frl.orst.edu> (FORRERJ@frl.orst.edu)
Subject: Thoughts on HF channel simulation

Everything I read and hear says that HF channels are really hard to
model and simulate realistically. But a repeatable simulation is
really important to have if you want to do controlled tests and
comparisons.

Would it be possible to probe a real HF channel, record its response
digitally, and then use that information in offline simulations that
could be replayed as often as desired?

Broadband impulses would make good channel probing signals. Where's
the woodpecker now that we need it? :-)

Phil

From rick@itron-ca.com Fri Mar 10 21:42:40 1995
Received: from itron-ca.com ([204.30.20.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id VAA23223 for <hfsig@tapr.org>; Fri, 10 Mar 1995 21:41:22 -0600
Received: (from audit@localhost) by itron-ca.com (8.6.9/8.6.9) id TAA07780; Fri, 10 Mar 1995 19:37:29 -0800
Received: from unknown(204.30.20.118) by gate.itron-ca.com via smap (V1.3mjr)
	id sma007778; Fri Mar 10 19:36:54 1995
Date: Fri, 10 Mar 95 19:23:32 PST
From: "Richard W. D. Booth" <rick@itron-ca.com>
Subject: RE: [HFSIG:308] Thoughts on HF channel simulation 
To: hfsig@tapr.org
X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc.
Message-ID: <Chameleon.4.01.950310193656.rick@rick.itron-ca.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


>Everything I read and hear says that HF channels are really hard to
>model and simulate realistically. But a repeatable simulation is
>really important to have if you want to do controlled tests and
>comparisons.
>
>Would it be possible to probe a real HF channel, record its response
>digitally, and then use that information in offline simulations that
>could be replayed as often as desired?
>
>Broadband impulses would make good channel probing signals. Where's
>the woodpecker now that we need it? :-)
>
>Phil
>
Good question but may have some difficulties:
1. Broadband impulses are a good way to make the measurements as long as the 
receiving "bandwidth" is large enough so that it does not distort the measurments.  
This includes the antenna and front end filters.  Not to mention the legal 
issues...hmmm
2. Narrow band or CW probing has the following problems.
Presumably the amplitude and phase of the incoming signal could be traccked if the 
receiver LOs were stable enough.  Measurement of doppler shift would require knowing 
the stability at both the transmit and receive ends...
3. Given the above CW measurment could be made then the results must be extended 
over the signal bandwidth of interest.  Assume a flat fading model where the 
measurement is assumed to apply to all frequencies in the band of interest?
Multitone probes could be used and the different phase and amplitude characteristics 
used to synthesize a time varying filter.   Sounds tough.

No doubt a repeatable model is necessary.  This must be availble to anyone interested 
in developing both hardware and software for the solution of the problem.  Fixing the 
"standard" channel model is likely the only way non subjective evaluations will be 
achievable...somehow the BS has got to be separable from the facts!!!
Rick Booth
w6nzk


From kurpiers@zeus.uet.e-technik.th-darmstadt.de Sat Mar 11 05:39:19 1995
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id FAA24879 for <hfsig@tapr.org>; Sat, 11 Mar 1995 05:39:15 -0600
Received: from zeus.uet.e-technik.th-darmstad (zeus.uet.e-technik.th-darmstadt.de) by rs2.hrz.th-darmstadt.de with SMTP id AA29048
  (5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Sat, 11 Mar 1995 12:35:40 +0100
Received: from hades.uet.e-technik.th-darmsta (hades.uet.e-technik.th-darmstadt.de [130.83.18.78]) by zeus.uet.e-technik.th-darmstadt (8.6.4/8.6.4) with ESMTP id MAA16023 for <hfsig@tapr.org>; Sat, 11 Mar 1995 12:35:38 +0100
From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de>
Received: from localhost (kurpiers@localhost) by hades.uet.e-technik.th-darmstad (8.6.4/8.6.4) id MAA16623 for hfsig@tapr.org; Sat, 11 Mar 1995 12:33:04 +0100
Message-Id: <199503111133.MAA16623@hades.uet.e-technik.th-darmstad>
Subject: RE: Thoughts on HF channel simulations
To: hfsig@tapr.org
Date: Sat, 11 Mar 1995 12:33:04 +0100 (MEZ)
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 472       

Hi!

This kind of research was done in the early 70's by Watterson et. al. and
lead to a widely accepted model which is described in the CCIR report
549-3 (1990). The original paper is:

Watterson, C.C., Juroshek, J.R. and Bensema, W.D., "Experimental
confirmation of an HF channel model", IEEE Trans. Comm. Tech., COM-18,
1970, pp. 792-803.

This model covers ionosperic transmissions with discrete Rayleigh fading
paths and is found to be very realistic.

73' Alexander
From bobs@tcet.unt.edu Sat Mar 11 11:29:55 1995
Received: from tcet.unt.edu (tcet.unt.edu [129.120.20.191]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id LAA25784 for <hfsig@tapr.org>; Sat, 11 Mar 1995 11:29:53 -0600
Received: by tcet.unt.edu (5.61-AIX-1.2/1.0)
	id AA148471 (for hfsig@tapr.org, from bobs/bobs@tcet.unt.edu); Sat, 11 Mar 95 11:25:14 -0600
From: bobs@tcet.unt.edu (Bob Stricklin)
Message-Id: <9503111725.AA148471@tcet.unt.edu>
Subject: Digital Test Files
To: hfsig@tapr.org
Date: Sat, 11 Mar 95 11:25:14 CST
In-Reply-To: <199503111133.MAA16623@hades.uet.e-technik.th-darmstad>; from "Alexander Kurpiers" at Mar 11, 95 05:45:41 am
X-Mailer: ELM [version 2.4dev PL17]

It should be possible to code the Waterson model in such a way that a
DSP unit would produce a standard test pattern. This test pattern could
then be transmitted and recorded by a second HF station equipped with
DSP so the pattern can be digitally recorded and stored. Then the file
could be placed on an FTP site as a test data block. I think this is
what Phil wanted. I have been thinking about the same thing. Actually I
would like to have a collection of digitally recorded files for all the
typical modulation or encoding methods used today. Then you could do
modeling and testing of filter code in EXCEL.

The TAPR DSP-93 should work will in this applaction.

Bob Stricklin, N5BRG

From fmitchell@rdcclink.rd.qms.com Sun Mar 12 16:34:33 1995
Received: from gatekeeper.qms.com (gatekeeper.imagen.com [161.33.3.1]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id QAA32744; Sun, 12 Mar 1995 16:34:29 -0600
From: fmitchell@rdcclink.rd.qms.com
Received: from imagen.sclara.qms.com (imagen.imagen.com) by gatekeeper.qms.com (4.1/SMI-4.1)
	id AA07864; Sun, 12 Mar 95 14:30:33 PST
Received: from sun470.rd.qms.com by imagen.sclara.qms.com (4.1/SMI-4.1)
	id AA01153; Sun, 12 Mar 95 14:30:32 PST
Received: from rdcclink.rd.qms.com by sun470.rd.qms.com (4.1/SMI-4.1)
	id AA15583; Sun, 12 Mar 95 16:27:27 CST
Received: from ccMail by rdcclink.rd.qms.com
	id AA795054599 Sun, 12 Mar 95 16:29:59 CST
Date: Sun, 12 Mar 95 16:29:59 CST
Message-Id: <9502127950.AA795054599@rdcclink.rd.qms.com>
To: netsig@tapr.org, bbssig@tapr.org, hfsig@tapr.org
Return-Receipt-To: fmitchell@rdcclink.rd.qms.com
Subject: unsubscribe


     
     unsubscribe fmitch@rd.qms.com
     subscribe fmitch@maf.mobile.al.us
From wtb@partyline.org Sun Mar 12 19:22:49 1995
Received: from uustar.starnet.net (uustar.starnet.net [128.252.135.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id TAA00788 for <hfsig@tapr.org>; Sun, 12 Mar 1995 19:22:47 -0600
From: wtb@partyline.org
Received: from partyline.org by uustar.starnet.net with UUCP id AA16724
  (5.67b/IDA-1.5 for hfsig@tapr.org); Sun, 12 Mar 1995 19:08:35 -0600
Received: by partyline.org
     id 0QV4E004 Sun, 12 Mar 95 19:07:23 -0600
Message-Id: <9503121907.0QV4E00@partyline.org>
Organization: Party Line Entertainment Network
X-Mailer: TBBS/PIMP v3.29
Date: Sun, 12 Mar 95 19:07:23 -0600
Subject: HF Simulations
To: hfsig@tapr.org


QEX, Dec '94, page 9, KE4BAD discusses two HF simulations you might
want to consider.    Bill  N0LIK  6219146  
reply wtb@partyline.org
From FORRERJ@frl.orst.edu Mon Mar 13 10:33:14 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAA05271 for <HFSIG@tapr.org>; Mon, 13 Mar 1995 10:33:10 -0600
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA04402 for <HFSIG@tapr.org>; Mon, 13 Mar 1995 01:08:49 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 13 Mar 95 8:28:28 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 13 Mar 95 8:28:04 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Mon, 13 Mar 1995 08:27:59 PST8PDT
Subject:       HFSIG Quaterly report
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <479A6CA084F@frl.orst.edu>

Hi All,

Here is a copy of HFSIG quaterly report. Please let me know
of any typo's, misspellings or items of interest that I missed
else that is how it goes into PSR.


73's

Johan



++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
HFSIG QUARTERLY SUMMARY: MARCH 1995

     Judging from comments expressed at the recent TAPR annual
meeting, the activities of HFSIG are followed by many and found
to contain interesting and useful material. HF digital is one
instance where technical advances and its adoption by the amateur
community, can be made with relative ease. Recent examples of
this are CLOVER II, G-TOR, and PACTOR II. Many fields in amateur
radio do not allow this degree of flexibility in adopting new
ideas and standards. The challenge of the HF channel offers a
unique opportunity to explore and bring together a mix of theory,
hardware, and software. Thanks to all your contributions that
makes this possible.    

Activities on HFSIG included several topics of interest:
     HF Channel Simulator,
     HF Modem Technology,
     Error-Control Coding.

HF Channel Simulator

     An HF channel simulator is an essential tool for HF modem
evaluation. For example, comparing TNC's or testing and tuning
algorithms. HFSIG's simulator effort has been based on a model of
HF propagation developed by Watterson et. al. (1). Simulating the
HF channel is a very complex subject - computer models such as
IONCAP simulates the nature of the ionosphere from input
parameters such as sunspot data, day and time for the year,
frequency of operation, also magnetic and geographical location.
For our purpose, however, a much simpler approach is followed. A
bandwidth-limited, stationary model with operational parameters
defined by CCIR recommendations (2) is used. This model is based
on work by the Watterson group using actual on-the-air broadband
transmissions and found statistically accurate. This is a well-
known method used for evaluation and testing purposes. For a
description of an actual implementation of such a model, please
see reference (3). 

     Recently, the interpretation of how to generate appropriate
fading functions was discussed by Tom McDermott and Alexander
Kurpiers. These functions have to represent two independent
complex bivariate Gaussian ergodic random processes, each with
zero mean and independent real and imaginary components with
equal R.M.S. values that produce Rayleigh fading. 

     Contributors for this discussion:

Rick Whiting, W0TN,
Barry Buelow, W0RJT,
Eric Silbaugh, N2NNP,
Glen Worstell, KG0T,
Rick Booth, W6NZK,
Jon Bloom, KE3Z,
Hugh Shane, N7UAX,
Tom McDermott, N5EG,
Alexander Kurpiers, DL8AAU.


HF Modem Technology

     Two objectives are evident: A) High speed modems for
eventual application over HF-based networks. B) Robust modems for
use under adverse conditions. These two objectives possibly
require different approaches and tradeoffs have to be made.

     Several promising approaches have been proposed. Orthogonal
signaling schemes were suggested by Alan Bloom and Phil Karn.
These schemes define multiple signaling channels spaced apart in
frequency such that these are essentially independent. Occupied
bandwidth varies depending on the number of channels and the
symbol rate.

     The family of MIL-STD-188, 16 and 39 parallel-tone modems,
are good examples of multi-tone modems that are already available
as commercial products, while ITA21, 6-tone, and ITA52, 12-tone
Piccolo modems are examples of implementation of the MFSK
approach. Ongoing work by Paul Russell and Pawel Jalocha
continues the parallel approach, whereas Adrian Nash is pursuing
the MFSK approach. Extensive literature is available on MFSK -
reference (4) is a good place to start. 

     Waveform synthesis for multi-tone signals was reviewed to
reduce extreme amplitude situations, i.e., noise-like spikes.
Eric Silbaugh has been looking into these using computer
simulation. Barry McLarnon pointed us to appropriate literature
on the subject. Please refer to reference (5) for further
details.
 
     Contributors in this discussion included:    

Rick Whiting, W0TN,
Walt DuBose, K5YFW, 
Phil Karn, KA9Q,
Hugh Shane, N7UAX,
Barry McLarnon, VE3JR,
Alan Bloom, N1AL,
Adrian Nash, G4ZHZ,
Charles Brain, G4GUO,
Kok Chen, AA6TY,
Rolf Sommerhalder, HB9CWP,
Frode Weierud, F/LA2RL,
Pawel Jalocha, (S53??),
Paul Russell (non-ham).

Error-Control Coding

     The purposes of error-control coding for future HF modems
are evident - dealing with fading, burst errors, interference and
power considerations. Phil Karn has been a regular contributor
and explained how best to employ block, convolutional, and
combined clock/convolutional methods. Pawel Jalocha suggested a
novel Hamming code for use with his experimental multi-tone
modem. Phil has promised to contribute his efforts of an advanced
convolutional coder that would ideally be suited for our future
HF digital work. We are looking forward to this.   

     Contributors in this discussion:

Phil Karn, KA9Q,
Pawel Jalocha.

General

     A growing library of code examples is available in the HFSIG
upload area:

ftp.tapr.org tapr/SIG/hfsig/upload

     Example code for the HF simulator, experimental parallel
modem, and error-control codes are available. In addition, DSP
code for AMTOR/PACTOR using a DSP sound card, also W9GR ported
denoising code is available for experimental purposes. 

Important notice:

     As scribe/HFSIG chair person, this probably will be my last
contribution for a while. Life's realities, in my case, my Ph.D
work, has required that most everything else must be put on hold.
HFSIG thus require assistance in this regard. Please contact Greg
if you like to volunteer to help out. This is a very capable and
nice group of people to work with.

     Thanks to each and all for participating, good luck, and
keep up the good work.


Johan Forrer
(KC7WW)
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From FORRERJ@frl.orst.edu Mon Mar 13 10:48:39 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAA05368 for <HFSIG@tapr.org>; Mon, 13 Mar 1995 10:48:35 -0600
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA04565 for <HFSIG@tapr.org>; Mon, 13 Mar 1995 01:24:14 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 13 Mar 95 8:43:53 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 13 Mar 95 8:43:35 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Mon, 13 Mar 1995 08:43:26 PST8PDT
Subject:       HF Channel simulator
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <479E8F363CF@frl.orst.edu>

Greetings,

I noticed some recent activities on the HF Simulator topic - good to hear 
the new ideas.

My $0.02: I think I hear three different things. 

1) Bob needs a standard "test recording" of different signals for purposes 
of tuning and developing filters.

2) Phil (I think) is interested in knowing the channel's actual transfer 
function. Knowing this, one may use adaptive techniques. This is
not easy as the channel is very dynamic, but I can see that if a form of 
training sequence is sent ahead of a data transmission by the ISS, and the 
IRS does the proper analysis, it may signal this back to the ISS 
for taking appropiriate action.

3) Modem evaluation: This is where we want to actually take a baseband 
signal from a modem under test, play all the tricks that the channel would 
do to the signal (multipath distortion, flat/selective fading, etc) and 
pass this modified signal to another modem to decode. I think it is 
understood that this cannot be done with a pre-recorded data signal. You 
would want to have the ability to signal message content at will such to 
obtain a good statistical representative sample of how well the modem 
performs.

The Watterson model that we are working on will perform (3) above. 
I do, however, see that (1) and (2) also have merit.

If someone want to take this on, how about start making recordings in 
".wav" format and upload it. This way we can can play with it a little.

Hope this helps.

73's

Johan, KC7WW
From aherhld@iaccess.za Mon Mar 13 14:03:31 1995
Received: from minnie.iaccess.za (minnie.iafrica.com [196.7.142.132]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id OAA06349 for <hfsig@tapr.org>; Mon, 13 Mar 1995 14:03:23 -0600
Received: from slipper116195.iaccess.za by minnie.iaccess.za with smtp
	(Smail3.1.28.1 #5) id m0roGGg-0007LdC; Mon, 13 Mar 95 21:59 GMT+0200
Message-Id: <m0roGGg-0007LdC@minnie.iaccess.za>
Sender: <aherhld@minnie.iafrica.com>
From: "Andries Herholdt" <aherhld@iaccess.za>
To: hfsig@tapr.org
Date:          Mon, 13 Mar 1995 21:47:16 +0000
Subject:       Re: Digital Test Files
Priority: normal
X-mailer: Pegasus Mail/Windows (v1.22)

On  Sat, 11 Mar 1995 , Bob Stricklin wrote :

> what Phil wanted. I have been thinking about the same thing. Actually I
> would like to have a collection of digitally recorded files for all the
> typical modulation or encoding methods used today. 

Perhaps you are familiar with Klingenfuss Publication's CD's ? They
are CD recordings of many typical HF modulation types including many
digital ones. Perhaps one could convert them to data format somehow.
The most elegant method would be to write a program ( Visual Basic?
) to read the data straight off the disk using a CDROM. A less
elegant way might be to record it straight off play it back through a 
sound card and get hold of the data there. Of course, Klingenfuss 
would have to give their blessing to such an endeavour !

One of my clients ( I am a freelance engineer ) have done what you 
suggest; they have a library on 1Gbyte laser disks of many signals
recorded down here ( za = South Africa ), which they use for 
comms research. They might even be persuaded to part with it, but 
probably not for free :(. ( nothing in it for me BTW ).

Perhaps I will be forgiven for slipping in a question at this point
that is slightly off the topic ?  At the moment I am working on some
data decoding software and one of the topics that came up was a 32
-tone version of MFSK that Klingenfuss calls CIS Piccolo and
apparently also is known as CROWD36. I can manage to extract the raw
symbols, but of course the alphabet is the main problem. I was
wondering : does anyone have any info on this, or could you point me
in the direction of an information source ?

Thanks in advance,
Andries.
--------------------------
Andries Herholdt
aherhld@iaccess.za
--------------------------
From wtb@partyline.org Mon Mar 13 19:37:30 1995
Received: from uustar.starnet.net (uustar.starnet.net [128.252.135.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id TAA08081 for <hfsig@tapr.org>; Mon, 13 Mar 1995 19:37:27 -0600
From: wtb@partyline.org
Received: from partyline.org by uustar.starnet.net with UUCP id AA23920
  (5.67b/IDA-1.5 for hfsig@tapr.org); Mon, 13 Mar 1995 19:21:19 -0600
Received: by partyline.org
     id 0R5FQ005 Mon, 13 Mar 95 19:19:37 -0600
Message-Id: <9503131919.0R5FQ00@partyline.org>
Organization: Party Line Entertainment Network
X-Mailer: TBBS/PIMP v3.29
Date: Mon, 13 Mar 95 19:19:37 -0600
Subject: access
To: hfsig@tapr.org


help.
wtb@partyline.org
From wtb@partyline.org Mon Mar 13 19:37:33 1995
Received: from uustar.starnet.net (uustar.starnet.net [128.252.135.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id TAA08087 for <hfsig@tapr.org>; Mon, 13 Mar 1995 19:37:29 -0600
From: wtb@partyline.org
Received: from partyline.org by uustar.starnet.net with UUCP id AA23915
  (5.67b/IDA-1.5 for hfsig@tapr.org); Mon, 13 Mar 1995 19:21:17 -0600
Received: by partyline.org
     id 0R5F4004 Mon, 13 Mar 95 19:19:36 -0600
Message-Id: <9503131919.0R5F400@partyline.org>
Organization: Party Line Entertainment Network
X-Mailer: TBBS/PIMP v3.29
Date: Mon, 13 Mar 95 19:19:36 -0600
Subject: HF simulation
To: hfsig@tapr.org


Can someone tell mee were to find out what a .wav file is?   How
is it put together and how is it played from the computer?:
    Bill  N0lik       reply wtb@partyline.org
From bstrick@tenet.edu Mon Mar 13 23:09:48 1995
Received: from Leslie-Francis.tenet.edu (Leslie-Francis.tenet.edu [198.213.2.9]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id XAA09495 for <hfsig@tapr.org>; Mon, 13 Mar 1995 23:09:46 -0600
Received: (from bstrick@localhost) by Leslie-Francis.tenet.edu (8.6.9/8.6.9) id XAA16718 for hfsig@tapr.org; Mon, 13 Mar 1995 23:05:44 -0600
From: Bob Stricklin <bstrick@tenet.edu>
Message-Id: <199503140505.XAA16718@Leslie-Francis.tenet.edu>
Subject: Re: [HFSIG:316] Re: Digital Test Files
To: hfsig@tapr.org
Date: Mon, 13 Mar 1995 23:05:42 -0600 (CST)
In-Reply-To: <m0roGGg-0007LdC@minnie.iaccess.za> from "Andries Herholdt" at Mar 13, 95 02:15:33 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 847       

According to Andries Herholdt:
> 
> 
Thanks for your comments. I think it will be easier to make my own files.
Sounds like the others may be a little hard to find. Also I have a better
idea what is required to generate the files from a radio with the DSP-93.


> Perhaps I will be forgiven for slipping in a question at this point
> that is slightly off the topic ?  At the moment I am working on some
> data decoding software and one of the topics that came up was a 32
> -tone version of MFSK that Klingenfuss calls CIS Piccolo and
> apparently also is known as CROWD36. I can manage to extract the raw
> symbols, but of course the alphabet is the main problem. I was
> wondering : does anyone have any info on this, or could you point me
> in the direction of an information source ?


Sorry, I can not help you on this.

Bob Stricklin, N5BRG

From nash@camail.ca.nmp.nokia.com Tue Mar 14 07:02:25 1995
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id HAA11808 for <hfsig@tapr.org>; Tue, 14 Mar 1995 07:02:20 -0600
Received: from mgw.nmp.nokia.com (mgw.nmp.nokia.com [131.228.233.85]) by noknic.nokia.com (8.6.9/8.6.9) with SMTP id OAA23492 for <hfsig@tapr.org>; Tue, 14 Mar 1995 14:57:56 +0200
Message-Id: <199503141257.OAA23492@noknic.nokia.com>
Received: from camail.ca.nmp.nokia.com by mgw.nmp.nokia.com with SMTP
	(1.38.193.4/16.2) id AA06356; Tue, 14 Mar 1995 07:54:30 -0500
Received: from bashful.ca.nmp.nokia.com (bashful) by camail with SMTP
	(1.37.109.14/16.2) id AA007685892; Tue, 14 Mar 1995 12:58:12 GMT
Date: Tue, 14 Mar 1995 12:58:12 GMT
From: Adrian Nash <nash@camail.ca.nmp.nokia.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:316] Re: Digital Test Files
Cc: nash@camail.ca.nmp.nokia.com

Hello Andries

>Perhaps I will be forgiven for slipping in a question at this point
>that is slightly off the topic ?  At the moment I am working on some
>data decoding software and one of the topics that came up was a 32
>-tone version of MFSK that Klingenfuss calls CIS Piccolo and
>apparently also is known as CROWD36. I can manage to extract the raw
>symbols, but of course the alphabet is the main problem. I was
>wondering : does anyone have any info on this, or could you point me
>in the direction of an information source ?

I presume that CIS Piccolo is pretty much the same as UK FCO Piccolo. It would
seem reasonable to assume that the alphabet is the same as Cyrillic radio
teletype using the NULL character as a 3rd shift. I think Mr Klingenfuss has
described this alphabet in his book.
 
Thought for the day : I wonder if the UK Foreign Offices' old LA2028 Piccolos
ended up in the CIS???  :-)

Regards

Adrian G4ZHZ
From FORRERJ@frl.orst.edu Tue Mar 14 10:28:12 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAA13658 for <hfsig@tapr.org>; Tue, 14 Mar 1995 10:28:09 -0600
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA11249 for <hfsig@tapr.org>; Tue, 14 Mar 1995 01:03:32 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 14 Mar 95 8:23:14 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 14 Mar 95 8:22:47 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Tue, 14 Mar 1995 08:22:45 PST8PDT
Subject:       Re: [HFSIG:318] HF simulation
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <49190E670A6@frl.orst.edu>

Bill,

A good place to look for programs and some documentation on .wav files are 
in the SIMTEL archives ( ftp to: oak.oakland.edu) and look in the
windows/sounds directory for a collection of sound record/playback
programs.

If you still have a question, I'll be happy to post the format.

73's

Johan
From bm@lynx.ve3jf.ampr.org Tue Mar 14 22:27:56 1995
Received: from hydra.carleton.ca (hydra.carleton.ca [134.117.12.18]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id WAA18240 for <hfsig@tapr.org>; Tue, 14 Mar 1995 22:27:53 -0600
Received: from lynx.ve3jf.ampr.org (root@lynx.ve3jf.ampr.org [44.135.96.100]) by hydra.carleton.ca (8.6.9/8.6.9) with SMTP id XAA31198 for <hfsig@tapr.org>; Tue, 14 Mar 1995 23:23:37 -0500
Received: by lynx.ve3jf.ampr.org (Linux Smail3.1.28.1 #14)
	id m0rokcY-0002pQC; Wed, 15 Mar 95 04:23 GMT
Message-Id: <m0rokcY-0002pQC@lynx.ve3jf.ampr.org>
From: bm@lynx.ve3jf.ampr.org (Barry McLarnon VE3JF)
Subject: Re: [HFSIG:308] Thoughts on HF channel simulation
To: hfsig@tapr.org
Date: Wed, 15 Mar 1995 04:23:40 +0000 (GMT)
In-Reply-To: <199503102140.NAA00427@servo.qualcomm.com> from "Phil Karn" at Mar 10, 95 03:42:31 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 2006      

> Everything I read and hear says that HF channels are really hard to
> model and simulate realistically. But a repeatable simulation is
> really important to have if you want to do controlled tests and
> comparisons.
> 
> Would it be possible to probe a real HF channel, record its response
> digitally, and then use that information in offline simulations that
> could be replayed as often as desired?

Definitely.  I brought this up briefly with Johan at the TAPR meeting.
About 10 years ago, when I was involved with HF stuff at my place of
work, we had an HF channel simulator with this capability built under
contract.  The simulator used the TMS32010, shortly after that chip was
first introduced.  Separate from the simulator was a PRBS probe
generator, clocked such that the main lobe would fit comfortably in the
passband (~2 kHz) of an ssb transmitter.  This was transmitted over
various HF channels, and the baseband receiver output (with AGC off)
recorded on an instrumentation tape recorder.  Nowadays, of course,
you'd use your sound card and store the received signal on your hard
disk.  The tape could then be played back into the simulator, where the
signal was digitized and correlated in real time against a stored
replica of the PRBS obtained from a back-to-back connection of the
transmitter and receiver.  The impulse response estimates from the
correlator were then used to adjust the tap weights of the simulator in
the main signal path.  This is very convenient, since it allows you to
reproduce the actual conditions on a real channel in a completely
repeatable fashion, with no dependence on the modulation format of the
system(s) under test.

I'll see if I can dig up some docs on the thing... I don't think there's
anything proprietary about it - it was a "one of" development and was
never made into a commercial product.
 
> Phil

Barry

-- 
Barry McLarnon  VE3JF/VA3TCP 
Ottawa Amateur Radio Club Packet Working Group
Email: bm@hydra.carleton.ca  or bm@lynx.ve3jf.ampr.org
From karn@qualcomm.com Wed Mar 15 14:15:50 1995
Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.80.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id OAA00457 for <hfsig@tapr.org>; Wed, 15 Mar 1995 14:15:37 -0600
Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.10/8.6.5) id MAA26223; Wed, 15 Mar 1995 12:15:54 -0800
Date: Wed, 15 Mar 1995 12:15:54 -0800
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199503152015.MAA26223@unix.ka9q.ampr.org>
To: hfsig@tapr.org
In-reply-to: <479E8F363CF@frl.orst.edu> (FORRERJ@frl.orst.edu)
Reply-To: karn@qualcomm.com
Subject: Re: [HFSIG:315] HF Channel simulator

>2) Phil (I think) is interested in knowing the channel's actual transfer 
>function. Knowing this, one may use adaptive techniques. This is

Not quite. I was mainly interested in finding a way to compare
different modems (or the same modem with experimental modifications)
in a repeatable and realistic way. Channel simulators based on
analytical models are repeatable, but people are concerned about their
realism. Actual on-air testing is certainly realistic, but it can be
hard to repeat consistently.

So my idea was to capture an actual HF channel over a particular span
of time (thus gaining realism) in such a way that it can be used
repeatedly. If I could record the measured response of a real HF
channel over some period of time, then a simulator could use it to
corrupt and modify my test signal exactly as if it had been actually
sent over the real channel. Even better, I would have the option of
repeating exactly the same channel simulation sequence with a
different modem and then comparing results on an even footing.

Of course, you wouldn't just measure an HF channel once, you'd want to
collect a wide variety of runs on different bands, paths and ionospheric
conditions.

Phil

From karn@qualcomm.com Wed Mar 15 19:26:57 1995
Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.80.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id TAA02143 for <hfsig@tapr.org>; Wed, 15 Mar 1995 19:26:53 -0600
Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.10/8.6.5) id RAA26557; Wed, 15 Mar 1995 17:27:20 -0800
Date: Wed, 15 Mar 1995 17:27:20 -0800
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199503160127.RAA26557@unix.ka9q.ampr.org>
To: hfsig@tapr.org
In-reply-to: <m0rokcY-0002pQC@lynx.ve3jf.ampr.org> (bm@lynx.ve3jf.ampr.org)
Subject: Re: [HFSIG:322] Re: Thoughts on HF channel simulation
Reply-To: karn@qualcomm.com

>first introduced.  Separate from the simulator was a PRBS probe
>generator, clocked such that the main lobe would fit comfortably in the
>passband (~2 kHz) of an ssb transmitter.  This was transmitted over
>various HF channels, and the baseband receiver output (with AGC off)
>recorded on an instrumentation tape recorder.  Nowadays, of course,

Bingo, this is exactly what I had in mind.

A possible alternative to the pseudo-random bit stream would be a
collection of closely spaced CW carriers of known amplitude and phase
across the passband of the SSB transceiver. You could then measure the
amplitude and phase variations of each and use the in a FFT-based
filter that simulates not only the HF channel, but the filters in the
radios.

Mathematically, both approaches are of course pretty much equivalent,
it's just a difference of implementation.

Phil


From wtb@partyline.org Wed Mar 15 22:29:12 1995
Received: from uustar.starnet.net (uustar.starnet.net [128.252.135.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id WAA02747 for <hfsig@tapr.org>; Wed, 15 Mar 1995 22:29:09 -0600
From: wtb@partyline.org
Received: from partyline.org by uustar.starnet.net with UUCP id AA22454
  (5.67b/IDA-1.5 for hfsig@tapr.org); Wed, 15 Mar 1995 22:11:02 -0600
Received: by partyline.org
     id 0V4DA00C Wed, 15 Mar 95 22:09:11 -0600
Message-Id: <9503152209.0V4DA00@partyline.org>
Organization: Party Line Entertainment Network
X-Mailer: TBBS/PIMP v3.29
Date: Wed, 15 Mar 95 22:09:11 -0600
Subject: [HFSIG:322] RE: THOUGHTS ON HF CHANNEL S
To: hfsig@tapr.org


Isn't it true that those of us who are planning to do our DSP on the
DSP93, a separate box from our computers, would want the channel
simulation (recordings) as analog tapes???
   Bill  N0LIK     
From karn@qualcomm.com Wed Mar 15 23:46:12 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id XAA02924 for <hfsig@tapr.org>; Wed, 15 Mar 1995 23:46:09 -0600
Received: (karn@localhost) by servo.qualcomm.com (8.6.10/QC-BSD-2.5) id VAA27211; Wed, 15 Mar 1995 21:44:22 -0800
Date: Wed, 15 Mar 1995 21:44:22 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199503160544.VAA27211@servo.qualcomm.com>
To: hfsig@tapr.org
CC: wtb@partyline.org
In-reply-to: <9503152209.0V4DA00@partyline.org> (wtb@partyline.org)
Subject: Re: [HFSIG:325] RE: THOUGHTS ON HF CHANNEL S

>Isn't it true that those of us who are planning to do our DSP on the
>DSP93, a separate box from our computers, would want the channel
>simulation (recordings) as analog tapes???

Not really. Who says I have to run my simulations on my DSP-93? Since
they don't have to run in real time, I could do them much more easily
on a general purpose PC.

Phil

From FORRERJ@frl.orst.edu Thu Mar 16 11:01:34 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id LAA05739 for <hfsig@tapr.org>; Thu, 16 Mar 1995 11:01:30 -0600
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA25010 for <hfsig@tapr.org>; Thu, 16 Mar 1995 01:36:19 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Thu, 16 Mar 95 8:56:05 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 16 Mar 95 8:55:44 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Thu, 16 Mar 1995 08:55:43 PST8PDT
Subject:       Re: [HFSIG:324] Re: Thoughts on HF channel simulation
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <4C21EE46B0C@frl.orst.edu>

Phil,


>>first introduced.  Separate from the simulator was a PRBS probe
>>generator, clocked such that the main lobe would fit comfortably in the
>>passband (~2 kHz) of an ssb transmitter.  This was transmitted over
>>various HF channels, and the baseband receiver output (with AGC off)
>>recorded on an instrumentation tape recorder.  Nowadays, of course,
>

I good idea I agree - this is actually what the Watterson group did, 
however,
after characterising the channel, went ahead and built the simulation 
model. The Watterson paper is actually good reading about acquiring channel
response. 

I have read a few papers where "the channel" is implemented as a FIR filter.
The FIR filter, in this case, having non-symetric filter coefficients, thus
able to produce most any amplitude/phase responses. The taps are then fed 
in real time from a stored data stream. This then gives "realism". I guess 
it would not be impossible to extract the coefficients for a given channel, 
given a procedure outline above. 

>Bingo, this is exactly what I had in mind.
>
>A possible alternative to the pseudo-random bit stream would be a
>collection of closely spaced CW carriers of known amplitude and phase
>across the passband of the SSB transceiver. You could then measure the
>amplitude and phase variations of each and use the in a FFT-based
>filter that simulates not only the HF channel, but the filters in the
>radios.
>
>Mathematically, both approaches are of course pretty much equivalent,
>it's just a difference of implementation.
>
>Phil
>

Johan,KC7WW

From karn@unix.ka9q.ampr.org Fri Mar 17 12:46:41 1995
Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.80.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id MAA14230 for <hfsig@tapr.org>; Fri, 17 Mar 1995 12:46:33 -0600
Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.10/8.6.5) id KAA00237; Fri, 17 Mar 1995 10:35:18 -0800
Date: Fri, 17 Mar 1995 10:35:18 -0800
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199503171835.KAA00237@unix.ka9q.ampr.org>
To: tcp-group@ucsd.edu, hfsig@tapr.org
Subject: Fano decoder uploaded to ftp.ucsd.edu

My Fano (sequential) decoder package is now available as

ftp://ftp.ucsd.edu/hamradio/packet/tcpip/incoming/fano.tar.gz
ftp://ftp.ucsd.edu/hamradio/packet/tcpip/incoming/fano.zip

Three different rate 1/2 constraint length 32 convolutional codes are
supported. The decoder operates on 8-bit soft decisions. A routine is
provided to build the decoder metric table assuming gaussian noise at
some estimated Es/N0. By substituting different metric tables, the
decoder can be adapted to run on other kinds of channels such as the
binary symmetric channel (BSC), i.e., with hard decoding.

Using GCC 2.5.8 on a 66 Mhz 486DX2 in protected (32-bit) mode, the
decoder runs at about 300,000 branches per second.  This translates
directly to 300,000 bits/sec on a "clean" channel. Noisy packets
decode more slowly, as is characteristic for a sequential decoder. The
performance curve is quite steep, as expected for a strong, long
constraint length code.  Simulation results show that at an Eb/N0 of
4dB, only about 1.6% of the packets decode at half speed or
slower. Below about 2.5-3dB, things start to fall apart as expected.

Although the encoder/decoder itself is in portable ANSI C, the test
driver assumes a UNIX (specifically BSDI1.1) environment with
curses/termcap. Also, the synthetic gaussian noise generator uses
log() and sqrt() quite heavily. Some 386/486 math libraries don't use
the native FPU instructions for these functions, so they can be quite
slow.

My Viterbi (maximum likelihood) decoder is next.

--Phil


From FORRERJ@frl.orst.edu Sat Mar 18 18:57:46 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id SAA21401 for <hfsig@tapr.org>; Sat, 18 Mar 1995 18:57:42 -0600
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id JAA07834 for <hfsig@tapr.org>; Sat, 18 Mar 1995 09:32:03 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Sat, 18 Mar 95 16:51:55 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Sat, 18 Mar 95 16:51:39 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Sat, 18 Mar 1995 16:51:33 PST8PDT
Subject:       Re: [HFSIG:328] Fano decoder uploaded to ftp.ucsd.edu
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <4FA0F1155A0@frl.orst.edu>

Phil,

Thanks - that is great news. I'll be trying that out soon.

-Johan
From karn@unix.ka9q.ampr.org Sat Mar 18 21:39:49 1995
Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.80.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id VAA22215 for <hfsig@tapr.org>; Sat, 18 Mar 1995 21:39:45 -0600
Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.10/8.6.5) id TAA01816; Sat, 18 Mar 1995 19:35:15 -0800
Date: Sat, 18 Mar 1995 19:35:15 -0800
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199503190335.TAA01816@unix.ka9q.ampr.org>
To: hfsig@tapr.org
In-reply-to: <4C21EE46B0C@frl.orst.edu> (FORRERJ@frl.orst.edu)
Subject: Re: [HFSIG:327] Re: Thoughts on HF channel simulation

>I have read a few papers where "the channel" is implemented as a FIR filter.
>The FIR filter, in this case, having non-symetric filter coefficients, thus
>able to produce most any amplitude/phase responses. The taps are then fed 
>in real time from a stored data stream. This then gives "realism". I guess 
>it would not be impossible to extract the coefficients for a given channel, 
>given a procedure outline above. 

Why not? Just send impulses down a real HF channel. What comes out of
the receiver will be, by definition, the impulse response of the
channel. These could be used in a time-varying FIR filter to later
simulate the same channel as many times as you wish.

Phil

From karn@unix.ka9q.ampr.org Sun Mar 19 01:20:37 1995
Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.80.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id BAA23563 for <hfsig@tapr.org>; Sun, 19 Mar 1995 01:20:33 -0600
Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.10/8.6.5) id XAA02636; Sat, 18 Mar 1995 23:16:03 -0800
Date: Sat, 18 Mar 1995 23:16:03 -0800
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199503190716.XAA02636@unix.ka9q.ampr.org>
To: hfsig@tapr.org, tcp-group@ucsd.edu
Subject: Viterbi decoder package released

As promised, I have uploaded my Viterbi decoder package:

ftp://ftp.ucsd.edu/hamradio/packet/tcpip/incoming/viterbi.tar.gz
ftp://ftp.ucsd.edu/hamradio/packet/tcpip/incoming/viterbi.zip

This package implements a coder and soft decision Viterbi (maximum
likelihood) decoder for the rate 1/2 K=7 NASA standard convolutional
code. It includes a driver program for test purposes.

The decoder runs at about 45.5 kilobits/sec on a 66 MHz 486DX2 under
BSDI1.1 and gcc 1.42. (Interestingly enough, it runs only about 40.8
kb/s under gcc 2.5.8, even with full optimization).  This is about
6.6x slower than my Fano decoder on a "clean" channel. But unlike a
Fano decoder, which bogs down on a noisy channel, the Viterbi decoder
runs at a constant rate even when the signal is very weak (though not
without errors, of course).

Phil
From ve6ahm@ve6ahm-1.ampr.ab.ca Sun Mar 19 17:16:12 1995
Received: from scapa.cs.ualberta.ca (scapa.cs.ualberta.ca [129.128.4.44]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id RAA26762 for <hfsig@tapr.org>; Sun, 19 Mar 1995 17:16:08 -0600
Received: from ve6kik by scapa.cs.ualberta.ca with UUCP id <13061-3>; Sun, 19 Mar 1995 16:10:55 -0700
Received: from ve6ahm-1.ampr.ab.ca by ve6kik.ampr.ab.ca with smtp
	(Smail3.1.28.1 #5) id m0rqRlK-000H8LC; Sun, 19 Mar 95 13:39 WET
Received: (from ve6ahm@localhost) by ve6ahm-1.ampr.ab.ca (8.6.9/8.6.9) id BAA00773 for hfsig@tapr.org; Mon, 20 Mar 1995 01:52:29 -0700
From: Les Davies <ve6ahm@ve6ahm-1.ampr.ab.ca>
Message-Id: <199503200852.BAA00773@ve6ahm-1.ampr.ab.ca>
Subject: Re: [HFSIG:331] Viterbi decoder package released
To: hfsig@tapr.org
Date: 	Mon, 20 Mar 1995 01:52:02 -0700 (MST)
In-Reply-To: <199503190716.XAA02636@unix.ka9q.ampr.org> from "Phil Karn" at Mar 19, 95 01:28:29 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 88        

What  can these packages be used for.  Also what additional is required for
them? 
Les

From karn@qualcomm.com Sun Mar 19 18:29:42 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id SAA27073 for <hfsig@tapr.org>; Sun, 19 Mar 1995 18:29:38 -0600
Received: (karn@localhost) by servo.qualcomm.com (8.6.10/QC-BSD-2.5) id QAA12011; Sun, 19 Mar 1995 16:27:10 -0800
Date: Sun, 19 Mar 1995 16:27:10 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199503200027.QAA12011@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <199503200852.BAA00773@ve6ahm-1.ampr.ab.ca> (message from Les Davies on Sun, 19 Mar 1995 17:26:34 -0600)
Subject: Re: [HFSIG:332] Re: Viterbi decoder package released

Both packages consist just of the encoder/decoder subroutines plus
test drivers. By themselves they are primarily intended for
experimentation and education. But you could also integrate them into
a system if you are so inclined.

Phil

From slewis@pacsat.demon.co.uk Sun Mar 26 16:08:05 1995
Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id QAA11627 for <hfsig@tapr.org>; Sun, 26 Mar 1995 16:08:00 -0600
Received: from pacsat.demon.co.uk by post.demon.co.uk id aa01997;
          26 Mar 95 22:50 GMT-60:00
Date: Sun, 26 Mar 1995 21:48:19 GMT
From: Simon Lewis <slewis@pacsat.demon.co.uk>
Reply-To: slewis@pacsat.demon.co.uk
Message-Id: <22@pacsat.demon.co.uk>
To: hfsig@tapr.org
Subject: ACARS SOFTWARE WANTED
X-Mailer: FIMail V0.9d
X-User: Alpha Test Version Of FI-Mail, DisWin  1.5C:\WINSOCK\WINDIS
Lines: 11

Hi All
I'm in need of some ACARS decoding software for the aero data system.
I know that this isnt an HF sig mode but any help from like minded data 
individuals would be appreciated.
-- 
+-------------------------------------------------------------------------+
|  73 From:  Simon Lewis GM4PLM - Helensburgh - Strathclyde - Scotland    |
| Packet: GM4PLM @ GB7SAN.#78.GBR.EU   Email: slewis@pacsat.demon.co.uk   |
| AMSAT - UK Member 4282     **** SUPPORT YOUR LOCAL AMSAT GROUP ****     |
+-------------------------------------------------------------------------+

From wtb@partyline.org Sun Mar 26 16:09:04 1995
Received: from uustar.starnet.net (uustar.starnet.net [128.252.135.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id QAA11649 for <hfsig@tapr.org>; Sun, 26 Mar 1995 16:09:01 -0600
From: wtb@partyline.org
Received: from partyline.org by uustar.starnet.net with UUCP id AA27407
  (5.67b/IDA-1.5 for hfsig@tapr.org); Sun, 26 Mar 1995 16:01:42 -0600
Received: by partyline.org
     id 0NVAH001 Sun, 26 Mar 95 16:59:27 
Message-Id: <9503261659.0NVAH00@partyline.org>
Organization: Party Line Entertainment Network
X-Mailer: TBBS/PIMP v3.30
Date: Sun, 26 Mar 95 16:59:27 
Subject: silence
To: hfsig@tapr.org


No info from SIG for over a week..  Is this normal or fault??
Bill   N0LIK
From FORRERJ@frl.orst.edu Mon Mar 27 11:09:44 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id LAA17048 for <HFSIG@tapr.org>; Mon, 27 Mar 1995 11:09:34 -0600
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA11130 for <HFSIG@tapr.org>; Mon, 27 Mar 1995 01:41:44 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 27 Mar 95 9:02:05 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 27 Mar 95 9:01:52 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Mon, 27 Mar 1995 09:01:46 PST8PDT
Subject:       HFSIG activities
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <5CA409544FC@frl.orst.edu>

Hi All,

After my plea for help, I have not heard from anyone, so without anyone 
to help out, this is what probably will be happening for a while:

1) Don't dispair - I have not lost interest. As soon as things settle down 
with my present time sink, there will be more time to spend on helping with 
the dissemination of ideas. With the way things are looking right now, this 
may be around September.

2) I am working with some on a few worthy projects - one of these are MFSK. 
It appears that this technology is far from dead and have taken a very 
interesting direction, for example: Viterbi decoding for both error-
control and synchronisation. More on this at a later opportunity.
The other is that I received a DSP-93 and will be porting a number of 
applications that I have running on the TI DSK to this platform. 
Initially, this will be the W9GR denoiser and the HF DSP modems for 
AMTOR/PACTOR.

Activity on HFSIG will be what you make of it, I'm sure there are lots 
of interesting ideas out there - use the opportunity.

73's

Johan, KC7WW


From fperkins@onramp.net Mon Mar 27 19:01:59 1995
Received: from ns.onramp.net (ns.onramp.net [199.1.11.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id TAA19759 for <hfsig@tapr.org>; Mon, 27 Mar 1995 19:01:57 -0600
Received: from 199.1.11.156 (dal56.onramp.net [199.1.11.156]) by ns.onramp.net (8.6.5/8.6.5) with SMTP id SAA23494 for <hfsig@tapr.org>; Mon, 27 Mar 1995 18:55:29 -0600
Date: Mon, 27 Mar 1995 18:55:29 -0600
Message-Id: <199503280055.SAA23494@ns.onramp.net>
From: fperkins@onramp.net
Subject: Re: [HFSIG:336] HFSIG activities
To: hfsig@tapr.org
X-Mailer: AIR Mail 3.X (SPRY, Inc.)

Hi Johan,

Great to hear you have joined the DSP-93 development team!

73 Frank WB5IPM

From wtb@partyline.org Tue Mar 28 11:10:52 1995
Received: from uustar.starnet.net (uustar.starnet.net [128.252.135.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id LAA23559 for <hfsig@tapr.org>; Tue, 28 Mar 1995 11:10:49 -0600
From: wtb@partyline.org
Received: from partyline.org by uustar.starnet.net with UUCP id AA23150
  (5.67b/IDA-1.5 for hfsig@tapr.org); Tue, 28 Mar 1995 10:52:49 -0600
Received: by partyline.org
     id 0GLIH005 Tue, 28 Mar 95 11:48:53 
Message-Id: <9503281148.0GLIH00@partyline.org>
Organization: Party Line Entertainment Network
X-Mailer: TBBS/PIMP v3.30
Date: Tue, 28 Mar 95 11:48:53 
Subject: [HFSIG:336] HFSIG ACTIVITIES
To: hfsig@tapr.org


Johan
Dont feel pressed, its only a hobby.  I was merely checking, not pushing.
You guys have finally pushed me into 486/50 with windows so I have weeks
of studying to do.  I'm also trying to get my hands on Phil's viterbi.zip
thru ftpmail and so far have failed miserably.  Good luck on your pursuits.
     BILL  N0LIK
From gjones@tenet.edu Tue Mar 28 12:12:07 1995
Received: from Alice-Thurman.tenet.edu (Alice-Thurman.tenet.edu [198.213.2.5]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id MAA23920 for <hfsig@tapr.org>; Tue, 28 Mar 1995 12:12:05 -0600
Received: (from gjones@localhost) by Alice-Thurman.tenet.edu (8.6.9/8.6.9) id MAA25465 for hfsig@tapr.org; Tue, 28 Mar 1995 12:05:29 -0600
From: Greg Jones <gjones@tenet.edu>
Message-Id: <199503281805.MAA25465@Alice-Thurman.tenet.edu>
Subject: Johan's Schedule
To: hfsig@tapr.org (HF SIG mailing)
Date: Tue, 28 Mar 1995 12:05:28 -0600 (CST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1639      

Greeting HF SIG.  Johan approached me before the TAPR annual meeting
regarding the fact that he would be very busy preparing for his dissertation
defense over the next 6 months.  I can literally understand his position, as 
I am taking my candidacy exams next week.

Problem:

1. HF SIG will come to a complete halt over the next 6 months unless we find
someone to step froward and at least provide the necessary facilitation to
continue discussion.

2. Johan will return and be available to help, but just not to do all the
talking during the period.

3. The group needs a scribe for the activity....Johan has been doing this as
well..and I can understand why he might feel a little over worked :-)

So - who has just a little time in the next 6 months to help organize and
report activity within the group....not to completely step into Johan's
shoes...just to help keep the topic of discussion focused until Johan can
return in full force and we can call him 'Dr. Forrer'.

We really need to find someone who will step forward and volunteer for
either some or all of this, or the HF SIG will be in a reduction mode.  I
would hate to see that, based on the tremendious dialog and work that has
been accomplished thus far.

If you think you can help - contact either Johan or myself.

Cheers - Greg


-----------------------------------------------------------------------------
President -- Tucson Amateur Packet Radio Corp
-----------------------------------------------------------------------------
TAPR Office (817) 383-0000  | Internet: gjones@tenet.edu
-----------------------------------------------------------------------------
From JALOCHA@chopin.ifj.edu.pl Wed Mar 29 05:05:07 1995
Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id FAA28499 for <hfsig@tapr.org>; Wed, 29 Mar 1995 05:05:00 -0600
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cyf-kr.edu.pl (8.6.11/8.6.11) with SMTP id MAA06372 for <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>; Wed, 29 Mar 1995 12:55:30 +0200
Date: Wed, 29 Mar 1995 11:55 GMT+1
Subject: Re: [HFSIG:336] HFSIG activities
To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>
Message-id: <547C7D2B20A02883@chopin.ifj.edu.pl>
X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org
X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>"

Let me say about what I am doing:

I am still at the stage of coding the parallel carrier modem into the
DSPCARD4. The current code can send out the tones, with a reasonable
initial phase set (so the Crest factor isn't too bad). The receiver's
FFT works too. There are some provisions for shifting the receiver's
sampling point for symbol synchronization.

Missing items:

1. Inter-symbol interference: how to send and receive symbols
   so they don't leak one into another across time and frequency.
   Yesterday I have worked out the problem (at last !) and I feel
   beeing myself on a straight way.
2. Bit endcoding/decoding.
3. Symbol synchronization.
4. Tuning indication.

I believe I have good ideas to follow in every of these aspects
so the whole project is only a matter of time...

By the way a little thing which came across my mind recently:

You remember that idea of putting same information at every carrier
and then doing a majority vote at the receiver.
If a,b,c,... are the bits to be sent the coding pattern looks like this:

     1 2 3 .... <- window number
 1   a b c . . . . .
 2   . a b c . . . .
 3   . . a b c . . .
 4   . . . a b c . .
 5   . . . . a b . .
 6   . . . . . a b .
 7   . .       . a b .
 8   . .         . a b .
 9   . .           . a b .
10   . .             . a b .
11   . .               . a b .
12   . .                 . a b .
13   . . . . . . . . . . . . a b .
14   . . . . . . . . . . . . . a b .
15   . . . . . . . . . . . . . . a b .

 ^
 carrier number

The intended feature of this scheme is time and frequency diversity.
But this scheme has another interresting feature: being mistuned
by one carrier makes little harm (your symbol timing shifts and
you loose 2 data streams out of 15 but the message is still decodeable).
I am not sure what happens if you get mistuned by a fraction of the carrier
spacing...

Are there schemes which provide resistance again any (but not to large)
mistune so you don't care much about tuning your receiver to these
last Hertz's ?

I could think of one such scheme: our elementary symbol would be
a constant rate sweep across the whole available band say 300..3000 Hz.
At the receiver you listen to the sweep through several narrow filters
(this is done with the help of FFT). Every filter gives you the same
data stream but shifted in time. Now you have time and frequency diversity
and reasonable insensitivity to mistuning your receiver (or possible Doppler
shift if it doesn't change too fast with time).

Pawel
From paulr@hagar.udc.neweast.ca Wed Mar 29 07:14:55 1995
Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id HAA29182 for <hfsig@tapr.org>; Wed, 29 Mar 1995 07:14:46 -0600
Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35)
	id AA27971; Wed, 29 Mar 95 13:08:00 GMT
Received: from cc:Mail by ccsmtp.udc.neweast.ca
	id AA796498681; Wed, 29 Mar 95 09:37:41 nst
Date: Wed, 29 Mar 95 09:37:41 nst
From: "Paul Russell" <paulr@hagar.udc.neweast.ca>
Encoding: 65 Text
Message-Id: <9502297964.AA796498681@ccsmtp.udc.neweast.ca>
To: hfsig@tapr.org
Subject: Re: [HFSIG:340] Re: HFSIG activities

     Pawel,
     
One thing I have come across that may help with being off frequency when using 
an FFT is: zero padding.

That is you use an FFT several times larger than necessary, and fill the extra 
points with zeros. 

        |     X                 |                    xXx        
        |     X                 |                  xXXXXXx      
        |     X                 |                xXXXXXXXXXx    
        |_____X__________       |______________xXXXXXXXXXXXXXx__________
              F                                       F         
        Original 64pt FFT                  Zero Padded 512pt FFT Output

The tones that were single "bars" in the original FFT, will now become "bumps" 
over the several new bars/bins around the frequency. If the tone was not on 
frequency in the original FFT, then one of the bins to one side of this 
frequency will have more energy in the new FFT. i.e. 8000Hz Sampling, 64point 
FFT = 125Hz/point. If zero pad the FFT to 512point = 15.625Hz/point which should
be sufficient resolution for radio frequency error? And all you do is add up the
power of the 8 groups of every (512/64=8) 8th point, and choose the point set 
that has the highest power as where the tones are centred. 

Care must be taken in that there may be some distortion to the phases of the 
points, although my initial simulations showed this to be negligible.

There have also been suggestions to me, that since our tones are orthogonal, 
that instead of zero padding, you repeat the FFT input data to fill the larger 
FFT input buffer. I understand that in some tests this has worked well. But in 
my own simulations I have seen occasional strange results (human error?). I am 
also worried about what may happen if the radio is off frequency, causing the 
received tones to no longer be completely orthogonal, and the resulting phase 
descrepancies at the repeat boundaries to causes erroneous FFT output.

As well as comments on above by anyone, I am extremely interested in your 
methods for solving:

1. Inter-symbol interference
        I am looking at shaping the signals using either sin() or sin()^2,
        this reduced harmonics at the phase/freqency changes between symbols 
        as the signal power drops to zero. But the shaping causes a large amount
        of energy in the adjacent FFT Bin. (Presently using sin() as higher
        centre to lobe ratio, and the further lobes are in the dirt anyway).
        Problem is shaping reduces the overall bit energy, reducing the SNR.

2. Bit endcoding/decoding.
        Are you planning an interleaved Golay code, or similiar? I've seen alot
        of coding software posted here. 

        I am uncertain if I correctly understand your diagram, showing the 
        staggered bit output on easy tone successively. If this is done, then 
        each bit is sent 16 times, won't some form of error correction coding be
        more efficient?

3. Symbol synchronization.
        If you shape the signal as in 1 above, then tracking the average audio  
        power gives you a clock. 

4. Tuning indication.
        If you use the Zero Padded FFT, then the Choice of point set gives a    
        course tuning indication. A larger FFT would bring it in closer.

Paul Russell


From FORRERJ@frl.orst.edu Wed Mar 29 11:22:57 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id LAA30652 for <hfsig@tapr.org>; Wed, 29 Mar 1995 11:22:44 -0600
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA03916 for <hfsig@tapr.org>; Wed, 29 Mar 1995 01:15:52 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 29 Mar 95 9:14:56 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 29 Mar 95 9:14:29 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Wed, 29 Mar 1995 09:14:22 PST8PDT
Subject:       HFSIG activities
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <5FA77D134D7@frl.orst.edu>

Hi All,

On a more positive angle - a short update:

Pawel - congratulations on your progress with the parallel modem. One
interesting article that I have recently worked through, concerning symbol 
synchronisation for MFSK, uses the Viterbi algorithm. This, in essence
is how they do it: 

You need to compute a sliding FFT, at least over several instances per 
symbol, then feed the output of the FFT bins at each instance into 
a decoder trellis. Do this over several symbols. The output of the decoder 
now will tell you the best path, in maximum likelihood sense, through 
the trellis, i.e. at which instance you have the center of the symbol. 
The same trellis is then also used for data error-control. For a 
description of the paper:

"Improved HF modem using convolutional coding." by B. Honary, F. Zolghadr, 
M. Darnell, and M.Maundrell. In Electronics & Communications Engineering 
Volume 4(2) April 1992. (Thanks to Frode for the reference).

I also have been following Adrian's (G4ZHZ) work on MFSK. This is really
outstanding - Adrian is busy dealing with some challenging issues.
I'll let Adrian give us a overview of this when he is ready - better will 
encourage him to write an article about it! Just to fill you in a bit: One 
of these is how to deal with the distortion inherent in a numerical
approach, i.e., local oscillator distortion, but also with dynamic range
of 16-bit DSP for FFT's vs. a correlator (matched filter) approach. These 
things are easy to talk about but another matter to live with in your actual 
implementations. This is where one have to carefully weigh your choice in
DSP chips - do you use the appropiate architecture, should you rather use
a floating point device? Another idea is to use a marriage between analog 
and DSP techniques. On this matter, if anyone has some ideas on a good 
analog front-end processor that can produce high resolution I/Q outputs, I 
am very interested.
 
We are still looking for help with this SIG: As you can gather from the 
recent contributions, please consider helping out for the next few months.

Thanks,

Johan, KC7WW 
From paulr@hagar.udc.neweast.ca Wed Mar 29 11:50:55 1995
Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id LAA30781 for <hfsig@tapr.org>; Wed, 29 Mar 1995 11:50:48 -0600
Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35)
	id AA29040; Wed, 29 Mar 95 17:43:59 GMT
Received: from cc:Mail by ccsmtp.udc.neweast.ca
	id AA796515241; Wed, 29 Mar 95 14:13:13 nst
Date: Wed, 29 Mar 95 14:13:13 nst
From: "Paul Russell" <paulr@hagar.udc.neweast.ca>
Encoding: 18 Text
Message-Id: <9502297965.AA796515241@ccsmtp.udc.neweast.ca>
To: hfsig@tapr.org
Subject: DSP Floating Point Unit

     FYI
     I am uncertain if I mentioned It before, but the best deal I've seen 
     on a Floating Point standalone DSP unit is the DSP Tools unit. 
     It connects to a PC via a parallel port, or runs standalone.
     Has a 33MHz TMS320C31 (50MHz available), and FLASH ROM for code 
     storage. Audio is via a TLC32040 AIC.
     
     $299.00 US (email Dave Jervis at DSP Tools for info:       
                        davejervis@aol.com)
     
     The floating point is easier than integer in that you don't have to 
     worry about dynamic range of the signal (clipping etc.) during the 
     stages of signal processing. But it costs more.
     
     
     Query: How mush is the DSP-93 and what processor does it use?
     
     Paul Russell

From karn@qualcomm.com Wed Mar 29 14:30:35 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id OAA31883 for <hfsig@tapr.org>; Wed, 29 Mar 1995 14:30:32 -0600
Received: (karn@localhost) by servo.qualcomm.com (8.6.10/QC-BSD-2.5) id MAA23656; Wed, 29 Mar 1995 12:26:30 -0800
Date: Wed, 29 Mar 1995 12:26:30 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199503292026.MAA23656@servo.qualcomm.com>
To: paulr@hagar.udc.neweast.ca
CC: hfsig@tapr.org
In-reply-to: <9502297964.AA796498681@ccsmtp.udc.neweast.ca> (paulr@hagar.udc.neweast.ca)
Subject: Re: [HFSIG:341] Re: HFSIG activities

Paul,

Your zero-padded FFT idea is basically a rectangular sampling window that's
shrunk to take up less than the whole time. Have you considered any of the
other sampling windows? There are many to consider: Hamming, hanning,
Kaiser, etc.

The right choice of sampling window is important in rejecting strong
in-band interference in a m-ary orthogonal FSK scheme. Otherwise, the
windowing artifacts would cause energy to spread over much of the spectrum
after the FFT.

Phil
From karn@qualcomm.com Wed Mar 29 14:36:08 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id OAA31973 for <hfsig@tapr.org>; Wed, 29 Mar 1995 14:36:01 -0600
Received: (karn@localhost) by servo.qualcomm.com (8.6.10/QC-BSD-2.5) id MAA23662; Wed, 29 Mar 1995 12:32:00 -0800
Date: Wed, 29 Mar 1995 12:32:00 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199503292032.MAA23662@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <5FA77D134D7@frl.orst.edu> (FORRERJ@frl.orst.edu)
Subject: Re: [HFSIG:342] HFSIG activities

Johan,

It's amazing how many uses people have found for the Viterbi algorithm
beyond straight FEC. Several textbooks discuss using it to do maximum
likelihood decoding of signals with intersymbol interference. In the
case of duobinary, a 3-level signalling scheme with deliberate,
controlled intersymbol interference, a Viterbi decoder buys back *all*
of the S/N loss that would otherwise result from going from 2 levels to 3.

Of course, the range of channels is somewhat limited by the Viterbi
decoder's exponential complexity function.

Phil

From JALOCHA@chopin.ifj.edu.pl Thu Mar 30 07:24:10 1995
Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id HAA04719 for <hfsig@tapr.org>; Thu, 30 Mar 1995 07:24:02 -0600
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cyf-kr.edu.pl (8.6.11/8.6.11) with SMTP id PAA17589 for <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>; Thu, 30 Mar 1995 15:14:12 +0200
Date: Thu, 30 Mar 1995 15:15 GMT+1
Subject: Re: [HFSIG:341] Re: HFSIG activities
To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>
Message-id: <3992D3FF80A03CC2@chopin.ifj.edu.pl>
X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org
X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>"

Hello Paul,

>As well as comments on above by anyone, I am extremely interested in your 
>methods for solving:
>
>1. Inter-symbol interference
>        I am looking at shaping the signals using either sin() or sin()^2,

After scratching my head a lot I decided to use sin()^2...
The numbers I work with right now are:

Sampling: 9600 Hz
FFT size: 128 points -> 64 frequency bins between 0 and 4800 Hz
I take even bins for data transmition, odd ones are for tuning.
I use 15 carriers, the first one is #8 (600 Hz), the last one is 2700 Hz.
This fits into 300-3000 Hz band.

Window: sin(x)^2 for x=0..PI, the total length of the window
is 128 samples (same as the FFT size). I use same window for transmit
and receive.

Spacing between symbols is 64 samples on I-part of the carrier
and same for the Q-part.
On both I- and Q-parts I use a BPSK coding: a 180 degrees change
in phase is a "0", no change is a "1". I- and Q- symbols are shifted
by 32 samples. This is the maximum bit packing you can do theoretically.

I'm going to try as well a carrier-on/carrier-off approach.

With sin()^2 window I expect inter-symbol crosstalks of about 1/6
to a symbol adjacent in time or in frequency, -1/12 to symbols
"across diagonals". For a symbol on the carrier #12 the crosstalk
pattern looks like this:

              ---|-----|-----|----> time:  |-----| = 64 samples

 carrier #14:  -1/12  1/6  -1/12

 carrier #12:   1/6    1    1/6

 carrier #10:  -1/12  1/6  -1/12

For a worst case the total crosstalk from adjacent symbols
reaches 1 so it may overcome the symbol you are interested in.
I correct for crosstalk by subtracting adjacent symbols
according to the above pattern.

>        this reduced harmonics at the phase/freqency changes between symbols 
>        as the signal power drops to zero. But the shaping causes a large amount
>        of energy in the adjacent FFT Bin. (Presently using sin() as higher
>        centre to lobe ratio, and the further lobes are in the dirt anyway).
>        Problem is shaping reduces the overall bit energy, reducing the SNR.

This is a very tricky thing: I would say that using rectangular window
(no shaping) makes your symbol's energy go to other frequency bins
(sounds the other way you say ?). Shaping makes the bit energy to concentrate
in the bin you want.
With rectangular window you don't see this energy being spread around
only because your other frequency bins are spaced just right.
If they were a bit off, you would notice...

>2. Bit endcoding/decoding.

This point was the way I encode the bits into the carrier states (look above).

>        Are you planning an interleaved Golay code, or similiar? I've seen alot
>        of coding software posted here. 

I forsee the following "simple" schemes:

0. no FEC at all (just to see how the modem alone works
1. 11 data + 4 CRC bits FEC code capable of correcting single error
2. 15 bit Walsh functions (how many error can these correct ?)
3. "send same bit 15 times" with majority coding at the receiver
   (cruel but can correct up to 7 errors).
4. with 24 carriers I might use a 12 data bits + 12 CRC bits Golay code
   which can correct up to 3 errors.

1,2,3 and 4 would additionally involve spreading the bits in time
to gain certain resistance against error bursts.
For details about 1 and 3 look my previous posts... or I send them
to you if you haven't got them.

For easy start I will use use AX.25 framing and protocol: I take a HDLC
frame and put the bits one by one (including the stuffing bits
and the frame markers) onto the carriers.

>        I am uncertain if I correctly understand your diagram, showing the 
>        staggered bit output on easy tone successively. If this is done, then 
>        each bit is sent 16 times, won't some form of error correction coding be
>        more efficient?

This is right: every bit gets send 15 times but I am not saying this is an
efficiant FEC - this was only an example, just to present the idea of
a signal which is little sensitive to a mis-tune at the receiver.

>3. Symbol synchronization.
>        If you shape the signal as in 1 above, then tracking the average audio  
>        power gives you a clock. 

Not so obvious I'm afraid... if you pack symbols as dense in time as I am
trying to.

>4. Tuning indication.
>        If you use the Zero Padded FFT, then the Choice of point set gives a    
>        course tuning indication. A larger FFT would bring it in closer.

Again not obvious when packing so dense in frequency as I am trying to do
but I hope I would get the mis-tune indication by using the odd carrier
information. Note, that for the moment I do not try to correct the mis-tune
- I only want to indicate it so the operator corrects the receiver.

Progress (rather regress) report:

I have made up cross-talk correcting code yesterday - seems to work fine.
Then I have put in the bit encode/decode (two BPSK's on I and Q
shifted by half the symbol length). The result: constant bit patterns
are passed well, but when I apply varying bit patterns I get some
bits flipped...
Might be a symbol timing problem - the timing is fixed now - but
adjusting the timing by hand didn't make much difference :-(
I hope it's a software bug somewhere and not a failure of a whole concept.

Pawel
From paulr@hagar.udc.neweast.ca Thu Mar 30 13:31:59 1995
Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id NAA06962 for <hfsig@tapr.org>; Thu, 30 Mar 1995 13:31:49 -0600
Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35)
	id AA02375; Thu, 30 Mar 95 19:24:43 GMT
Received: from cc:Mail by ccsmtp.udc.neweast.ca
	id AA796607685; Thu, 30 Mar 95 15:52:42 nst
Date: Thu, 30 Mar 95 15:52:42 nst
From: "Paul Russell" <paulr@hagar.udc.neweast.ca>
Encoding: 60 Text
Message-Id: <9502307966.AA796607685@ccsmtp.udc.neweast.ca>
To: hfsig@tapr.org
Subject: Re: [HFSIG:344] Re: HFSIG activities



>>Your zero-padded FFT idea is basically a rectangular sampling window 
that's shrunk to take up less than the whole time. Have you considered any 
of the other sampling windows? There are many to consider: Hamming, 
hanning, Kaiser, etc.

The right choice of sampling window is important in rejecting strong 
in-band interference in a m-ary orthogonal FSK scheme. Otherwise, the 
windowing artifacts would cause energy to spread over much of the spectrum 
after the FFT.

Phil<<


I shape the Initial FFT Buffer before zero padding. I use either 1/2 a sine 
cycle ( sin() ), or a raised cosine ( sin()^2 ). I also preshape the transmit 
symbols with either sin or sin^2. The resultant receive symbols are thus shaped 
by either sin^2 or sin^4, as well as the noise being windowed. The Energy spread
into adjacent FFT Bins is a problem. 

I like the Preshaping of the Tx symbols at the symbol rate as it provides a 
clock to the receiver, and reduces Tx spikes/harmonics at the 
phase_changes/symbol_boundaries in DPSK. Although it also reduces your average 
Tx Energy per bit.

I'm doing simulations to analyse the Sliding FFT Window that Pawel is using, 
where the FFT input buffer is longer than the symbol. 

I think a Preshaping with a sin() at the symbol rate (64pt), and a sin()^2 
windowing in the receiver that is twice the width of the symbol (128pt) is 
giving me my best results:

  For DPSK, Each symbol 180degree shifted from previous: 64samples/symbol
  Receiver 128Pt FFT centred on Rx symbol.
  Best Combinations from simulations so Far:

    Tx              Rx              128pt FFT Lobe Magnitudes
    Shaping         Windowing       (Only every 2nd point used)
                                    Centre: lobe 2 : lobe 4 : lobe 6
    None            Sin()^2 128pt     1   :  1/3   :  1/15  :  1/36   (Pawel's?)
    Sin() 64pt        None            1   :  1/3   :  1/15  :  1/36   
    Sin() 64pt      Sin() 64pt        1   :  1/2   :   0    :   0     
    Sin() 64pt      Sin()^2 128Pt     1   :  1/2   :   0    :   0     

  A 64 point FFT would also work, although the larger gives more frequency      
  resolution. Test with a 512 point zero padded FFT gave the same ratios (at the
  corresponding bins) with more frequency resolution.

In simulations I have seen the windowing "artifacts" spread quite well across 
the band if the wrong window is chosen, or misalligned <grin>.

The purpose of the zero-padding is to give more frequency resolution by using a 
larger FFT, without increasing the symbol period. You do not get something for 
nothing as the "spikes" in the FFT spread out and it requires more memory and 
processing time, but it can help resolve where your carrier tones are (highest 
peaks) and thus indicate how far off frequency your radio may be.

Paul


From paulr@hagar.udc.neweast.ca Thu Mar 30 13:40:55 1995
Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id NAA07009 for <hfsig@tapr.org>; Thu, 30 Mar 1995 13:40:48 -0600
Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35)
	id AA02498; Thu, 30 Mar 95 19:33:47 GMT
Received: from cc:Mail by ccsmtp.udc.neweast.ca
	id AA796608226; Thu, 30 Mar 95 16:01:34 nst
Date: Thu, 30 Mar 95 16:01:34 nst
From: "Paul Russell" <paulr@hagar.udc.neweast.ca>
Encoding: 23 Text
Message-Id: <9502307966.AA796608226@ccsmtp.udc.neweast.ca>
To: hfsig@tapr.org
Subject: Re: [HFSIG:346] Re: HFSIG activities

Pawel, 

I have printed out all the messages I have received from hfsig re your 
design. I definitely need to re-read all of it slowly.

I'm having trouble understanding the advantage of the sliding window FFT, 
hopefully I'll find the light <g>.

One note: You mention you are planning on using tones from 600-2700Hz. I 
realize HF voice audio bands are supposed to be 300-3000Hz, but I have 
never seen a radio provide this. I would recommend dropping your upper 
tone, or shifting the whole down by 75Hz (525-2625). I have come across 
several commercial grade radios that only receive from ~375-2675Hz. I have 
even hit an older Harris RF230 that only passed 400-2500Hz. If the design 
is ment to operate on a wide range of radios, you may need to narrow your 
bandwidth requirements. Either lowering the sampling rate (8000Hz?) or 
using less tones may suffice. The equipment you are using may not have this 
limitation, this is just a warning.

Now off to study the printouts... 


Paul

From JALOCHA@chopin.ifj.edu.pl Fri Mar 31 10:05:38 1995
Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAA12275 for <hfsig@tapr.org>; Fri, 31 Mar 1995 10:05:27 -0600
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cyf-kr.edu.pl (8.6.11/8.6.11) with SMTP id RAA27830 for <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>; Fri, 31 Mar 1995 17:55:11 +0200
Date: Fri, 31 Mar 1995 17:57 GMT+1
Subject: Re: [HFSIG:347] Re: HFSIG activities
To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>
Message-id: <195B304F80A0639F@chopin.ifj.edu.pl>
X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org
X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>"


Hello Paul (and others),

>    Tx              Rx              128pt FFT Lobe Magnitudes
>    Shaping         Windowing       (Only every 2nd point used)
>                                    Centre: lobe 2 : lobe 4 : lobe 6
>    None            Sin()^2 128pt     1   :  1/3   :  1/15  :  1/36   (Pawel's?)
>    Sin() 64pt        None            1   :  1/3   :  1/15  :  1/36   
>    Sin() 64pt      Sin() 64pt        1   :  1/2   :   0    :   0     
>    Sin() 64pt      Sin()^2 128Pt     1   :  1/2   :   0    :   0     

I preshape both at the Tx and at the Rx with 128 pt sin()^2.

>In simulations I have seen the windowing "artifacts" spread quite well across 
>the band if the wrong window is chosen, or misalligned <grin>.

A bit different view at the Fourier Transform:

While doing the transform you effectively make several
time-domain convolutions with these functions:

sin(k*2*pi*f*t)*window(t) and cos(k*2*pi*f*t)*window(t).

t is time, f is the base frequency of your FFT (sampling-rate/FFT-length).

You can regard the FFT output as a set of outputs from a series of FIR filters
having the above shapes.

Now, if you want to separate your frequencies as much as possible,
those FIR filters must be sharp. Not narrow, but sharp
- that is the "walls" must be sharp and the out of band attenuation
must be strong.

If you want a sharp FIR filter you must make it long.
For low inter-carrier crosstalk the FFT length should be several
times larger than the symbol time.
For example try the FFT length of 256 with this window:

sin(pi/64 * t)  t = -127.5 .. 127.5 (256 values to form a 256 point window)

You get 128 frequencies but you use every forth one to transmit
symbols spaced at 64 points. Use the above window for both
the receiver and the transmitter.
You notice very low inter-carrier crosstalk at the price of having
overshoot-type crosstalk inbetween succesive symbols on same carrier.

I am now stuck with my ideas for phase-differential coding...
getting the bits out while attempting to cancels the inter-symbol
crosstalks and getting the symbol timing is too much.
For the moment I am going to switch to carrier-on/carrier-off aproach :-)
and test few other ideas.

Pawel
From paulr@hagar.udc.neweast.ca Fri Mar 31 12:57:29 1995
Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id MAA13916 for <hfsig@tapr.org>; Fri, 31 Mar 1995 12:57:24 -0600
Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35)
	id AA05815; Fri, 31 Mar 95 18:50:13 GMT
Received: from cc:Mail by ccsmtp.udc.neweast.ca
	id AA796692015; Fri, 31 Mar 95 15:18:55 nst
Date: Fri, 31 Mar 95 15:18:55 nst
From: "Paul Russell" <paulr@hagar.udc.neweast.ca>
Encoding: 33 Text
Message-Id: <9502317966.AA796692015@ccsmtp.udc.neweast.ca>
To: hfsig@tapr.org
Subject: Overlapped Symbol windowing (Was HFSIG Activities)

Pawel,
        I'm Still having trouble understanding the advantages of the 
overlapped windowing on Tx and Rx instead of just windowing at the symbol 
rate. When there is a run of same phase symbols, the tone becomes 
continuous at the Tx, whereas when the phase is shifting the tone is 
"modulated" by the windowing. This leads to more energy/bit in steams of 
same phase symbols then in streams of alternating phase bits. Also it uses 
much more processing power and memory.

I have done up simulations, and anyone can have the file/printout. Just email 
the request and I'll email/fax back the results (simulation plots). The file 
shows the effects of phase modulating with 128pt sin()^2 shaping on 64pt 
overlapped bits for a single channel/tone.
        Word Document    160K
        Postscript File  500K
        Or I'll Fax It

The result of adding 128pt sin()^2 shaped symbols, overlapped at 64 pts, of 
alternating phases (+/-90degrees = 180degree shifted) is the same as a 64pt 
sin() shaped signal. (Unless there is no phase shift which gives continuous 
tone). This is what my simulations produced. Is this correct, or Do I have a 
flaw in my data?

Also, By shaping the symbols so that they are timewise independent, we may be 
able to use multiple phases when the channel is better, thus doubling 
(4phases=2bits) or tripling (8phases=3bits) or data rate? Although the protocol 
would have to detect and adjust for this?

Paul Russell
paulr@neweast.ca

If I don't figure this out soon, you are all either going to shoot me or start 
ignoring me :-)

